- User Since
- Jan 13 2015, 10:58 PM (266 w, 11 h)
Mon, Feb 17
Fri, Feb 7
I believe you are correct. NFS is not POSIX compliant, since it checks
permissions on read/readdir and not just open.
Sun, Jan 26
Dec 31 2019
Dec 30 2019
Dec 29 2019
This version of the patch just deleted p_nlminfo instead of
replacing it with p_spare.
The offsets in kern_thread.c have been adjusted, which the
comment indicates is sufficient for a change to "struct proc" in head.
I'll update the patch with a version that doesn't have p_spare in a day or two.
One file got missed for the previous version of the deletion patch.
This patch is completely different than the previous one.
It prepares the source tree for removal of sys/nfs/nfs_lock.c,
since this code uses Giant and has not been running by default
since May 2008.
Dec 28 2019
Well, you might get a chuckle about this...
Turns out this code that I've been hacking to get rid of Giant
never gets executed.
Dec 27 2019
Further to kib@'s comment, here is how I understand the algorithm.
nfs_dolock() is called when a process does a file lock request on an NFSv3
mount that doesn't have the "nolockd" mount option.
It locked Giant to protect the code in lines 283-294 (before patch), but
except for the rare case where the malloc(M_WAITOK) in nfslock_send()
slept, held it until the tsleep() call at line#325.
This version of the patch recodes the loop so that I think it is more readable.
It does not really change the semantics in a significant way.
I chose not to unlock/relock the mutex around nfslock_send(), since the
unpatched version would normally only unlock/relock Giant at the tsleep() call.
(Yes, it is possible that there would have been a sleep and associated unlock/relock
of Giant in the unpatch nfslock_send() via the malloc(..M_WAITOK), but it wouldn't
normally have occurred.)
I think your understanding is correct, in that the locking is to protect
use of p_nlminfo.
If I read it correctly, nlminfo_release() is only called from code in exit1()
when the process is terminated, so it would no longer be doing any locking.
(It is kind of a weird hack, where nlminfo_release_p is set to nlminfo_release()
and then nlminfo_release_p is checked for non-NULL and called during process exit.)
Dec 26 2019
Dec 25 2019
Dec 22 2019
Dec 20 2019
Dec 14 2019
Dec 13 2019
Dec 12 2019
Dec 8 2019
Dec 7 2019
Dec 6 2019
Dec 4 2019
Dec 2 2019
Nov 28 2019
Nov 25 2019
Nov 22 2019
Nov 17 2019
Nov 16 2019
Add a check for nfsrv_nfsuserd == STARTSTOP to the wakeup(), to avoid extraneous
Also add a KASSERT() for nfsrv_userdupcalls.
Oops, I've realized there are other fields of nfsrv_nfsuserdsock that are
used by newnfs_request(), so holding a reference count on *nr_client isn't
Move the NFSUNLOCKNAMEID() up so that it only updates the nr_client field
before unlocking and add a comment related to this.
Updated my inline comment reply.
Replied to inline comments.