In message <1086415885.842307.9406.nullmailer@yamt.dyndns.org>,
YAMAMOTO Takashi writes:

>> Several of the callers which pass soreceive a struct mbuf ** don't
>> even set the uio_segflag. Heck, before the changes I commited last
>> month, there was at least one call where the values of both
>> uio_segflag and uio_procp passing were uninitalized garbage from prior
>> on-stack contents.
>> 
>> I guess the cleanest way to fix this is to add a new UIO segflag,
>> UIO_NONE, meaning that only uio_resid is valid; and also uio_procp, if
>> its value is non-NULL, but a NULL value is allowed).  Do you buy that?
>
>in that case, for what do you use uio_procp?

<Deep breath>.  Because Matt Thomas convinced me that was a better
approach than adding a new, explicit struct proc * argument to
soreceive(), for the cases where soreieve() had previously been using
curproc.

((The reason for that <deep breath> is, the discussion
seems to've become circular.))


Even so, I personally would hope soreceive() does not use the
uio_procp when passed a non-NULL struct mbuf **mp argument.
Regrettably, the soreceive() source code has evolved somewhat beyond
the comment in soreceive() which says in that case, *only* the
uio_resid is used, and only as a limit on how much data to
return in the mbuf chain.

soreceive() now has ifdef'ed out code which uses uio->uio_procp for
process-based accounting of send/receive ops.  Plus the changes where
I now pass that value downward.  (As I said a few days back, I think I
should back those changes out.)


>internalize/externalize things only make sense for UIO_USERSPACE, i think.

Almost goes without saying,, once you put it that way.  Unless,
just possibly for moving open-fds between userspace and kthreads?
Do kthreads have an per-process open-file table?

How about KASSERT(uio->uio_segflag == UIO_USERSPACE), for externalize
ops in soreceive()?