Subject: Re: curproc removal (NFS, ...)
To: David Young <firstname.lastname@example.org>
From: Jonathan Stone <email@example.com>
Date: 05/24/2004 11:56:34
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)
>> 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
>> -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. ]]