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