Subject: Re: curproc removal (NFS, ...)
To: Eric Haszlakiewicz <erh@nimenees.com>
From: Steven M. Bellovin <smb@research.att.com>
List: tech-kern
Date: 05/26/2004 11:51:56
In message <20040526051954.GA1522@diana.nimenees.com>, Eric Haszlakiewicz write
s:
>On Tue, May 25, 2004 at 01:21:14PM -0700, Jonathan Stone wrote:
>> Suppose you wish to call soreceive(). Suppose the socket you want to
>> pass to soreceive() might be a PF_UNIX socket (maybe it is, maybe it
>> isn't, but you cannot say for sure ahead of time).
>>
>> Your call to soreceiv() might therefore call (*pr->pr_dom->dom_externalize)(
>).
>> For PF_UNIX sockets (the only non-NULL dom_externalize?), that means
>> calling unp_externalize(). unp_exernalize() now requires a valid struct pro
>c *,
>> in place of the curproc it used to grab.
>>
>> We have agreed not to go back to using use curproc. How, then, would
>> you suggest we pass the necessary struct proc * to soreceive(), so it
>> can pass it onto pr->pr_domain->dom_externalize?
>
> Can't this end up in the so_pcb, get filled in at connect time
>and then be entirely private to unix domain sockets? I just barely glanced
>at the code, by it seems that unix domain sockets end up with a struct unpcb
>stored in the socket so_pcb, which could have a struct proc * added to it.
>no?
What about forks? Aren't the PCBs per-socket, and thus inherited by
more than one process after a fork?
--Steve Bellovin, http://www.research.att.com/~smb