Subject: Re: RFC: client-side NFS locking
To: None <tech-kern@NetBSD.org>
From: Edgar =?iso-8859-1?B?RnXf?= <email@example.com>
Date: 07/26/2006 22:47:14
Sorry for the double posting. If I only knew how to delete the first
before harvesters start grabbing the address from the archives.
I'm unsure whether I'd better chosen tech-net.
Of course I forgot things:
All patches are against 3.0.
There's a typo (I think) in rpcsvc/nlm_prot.x, which read
nlm4_denied_nolock, but the doc says nlm4_denied_noclocks.
The code in lockd_lock.c (which I turned into lock_server.c)
in send_granted() appears a bit over-tricky to me. While the static
declaration of retval and retval4 should set the cookie.n_byte fields
to NULL, so the first call to NLM_GRANTED will allocate and fill in
that pointer, what if a later call will have to deal with a larger
cookie? Shouldn't the trick be at least commented?
My code in sys/nfs/nfs_lock.c is intended to be non-biglock-SMP
safe, but it's probably not in-kernel-preemting safe.