In message <20040524174012.GR29323@che.ojctech.com>David Young writes
>On Mon, May 24, 2004 at 07:00:26PM +0200, Matthias Drochner wrote:
>> 
>> Hi -
>> I'm getting tons of kernel warnings now on a -current diskless box:
>> nfs_send: proc botch: rep 0x0 arg 0x0 curproc 0xc71dc1d0
>> nfs_send: proc botch: rep 0x0 arg 0x0 curproc 0xc71dc008
>> nfs_send: proc botch: rep 0x0 arg 0x0 curproc 0xc7e068f4
>> [...]

Oh, drat. Isn't that warning inside an #ifdef DIAGNOSTIC?  If that's
still too noisy, I'll wrap it inside an if (!warned)/warned=1, or up
it to #ifdef DEBUG.  Or probably both.

I left the warning in because, at least semantically, its a bug
(note the message doesn't always fire!) and I hope to fix it very soon.
Perhaps by comparison against Rick Macklem's NFSV4 code, where we heard
curpoc is now completely gone.


>> Looking at the reason I've found 3 NFS calls for now which pass
>> a 0 proc* down:
>> -the asynchronous readahead (nfssvc_iod)
>> -the sillyrename stuff (nfs_removeit)
>> -readlink
>> 
>> This appears easily fixed, but it is not obvious what the
>> proc pointer is used for in every case. This might be:
>> -scheduling (ultimatively to be passed to ltsleep())
>> -access rights
>> -accounting
>> -address space for virtual addresses

Fair point.  I think the short, honest answer is; ``right now, nobody
really knows''.  Its also in a state of flux.

Example #1, there are changes in progress to do accounting of messages
in soreceive(): which would mean soreceive() uses its uio->uio_procp
for accounting and access rights.  sys/nfs used to build a struct uio*
on the stack, and handed it off to the socket layer, without ever
setting the uio->uio_procp (the value of that field was garbage from
previous stack content).

My eventual goal here is simple: To quote nathanw, ``curproc should die''.

For now, I'm trying to eliminate all uses of curproc from within the
socket layer. My medium-term goal is to eliminate uses of curproc from
data-movement socket operations (sosend, soreceive, and the dynamic
call graph through and below them).

Eliminating curproc will also have the side-effect of making it safe
to call socket data-movement operations (sosend, soreceive) from a
context where curproc might be NULL; and in any case should not be
assumed to be related to the socket-level operation being performed.

Until the change I made last weekend, NetBSD would use curproc in
those call-paths, in ways which other modern CSRG-derived networking
stacks haven't done for quite some time.  That in turn has a major
bearing on the usability of kcont(9).   Think of this as the  first
small steps down a long path toward an NFS server that doesn't need
process context, and therefore doesn't need a context-switch per NFSop.


[[The restriction to `data movement' is because for now, I chose not
  to step up to the plate of removing curproc from the VFS layer.
  Unix-domain socket creation and binding uses curproc *all over*
  when sockets are being bound to, connected to, or unbound from,
  filesystem names. ]]