Jeff Layton wrote:
>
> This is the problem we have now with the BKL. So much of
> rpc/nlm/nfs/nfsd runs under it that it's nearly impossible to tell what
> it's intended to actually protect.
Practically none of nfsd runs under BKL, except the startup and shutdown
sequences and some of the write handlers for /proc/fs/nfsd/.
> If we're going to start a push
> toward BKL removal, my humble request is that we try to be as explicit
> as possible about what locks protect what data structures.
>
See comments in net/sunrpc/svcsock.c and net/sunrpc/svc.c. Here the BKL
is protecting the global nfsd_serv pointer.
--
Greg Banks, P.Engineer, SGI Australian Software Group.
The cake is *not* a lie.
I don't speak for SGI.
On Mon, 19 May 2008 19:34:27 -0700
Greg Banks <[email protected]> wrote:
> Jeff Layton wrote:
> >
> > This is the problem we have now with the BKL. So much of
> > rpc/nlm/nfs/nfsd runs under it that it's nearly impossible to tell what
> > it's intended to actually protect.
> Practically none of nfsd runs under BKL, except the startup and shutdown
> sequences and some of the write handlers for /proc/fs/nfsd/.
You're quite correct. I was thinking mainly of lockd (which runs
entirely under the BKL) and large swaths of NFS client and RPC code
which also do. It looks like nfsd doesn't do as much under the BKL (and
that is definitely a good thing!).
> > If we're going to start a push
> > toward BKL removal, my humble request is that we try to be as explicit
> > as possible about what locks protect what data structures.
> >
> See comments in net/sunrpc/svcsock.c and net/sunrpc/svc.c. Here the BKL
> is protecting the global nfsd_serv pointer.
>
Ok. Good to know. When I do the kthread conversion I'll make sure
that's protected, though with Neil's mutex patch I shouldn't need to
change much of the locking, if any.
--
Jeff Layton <[email protected]>