- User Since
- Jan 13 2015, 10:58 PM (157 w, 1 d)
Mon, Dec 25
The ones for nfs look ok. (I have not reviewed the rest of them.)
I would suggest that they be done as separate commits.
Tue, Dec 19
Dec 18 2017
Dec 9 2017
Dec 6 2017
It looks ok to me, but I am not familiar enough with socket handling to
be sure doing this is ok. As such, I suspect it's fine, but won't actually
accept it. (Someone else already has accepted it.)
Dec 4 2017
Adding a KASSERT() to check for correct lock acquisition when incrementing/decrementing
the counter is more awkward than it might seem.
The obvious place for such a check would be nfsrv_freedeleg(), which is where
this counter is decremented. Unfortunately this function is called during module
unload, when there are no nfsd threads and no locks held.
The locations where the counter is incremented are all in rather long chunks of
code that is updating state. Putting a KASSERT() at the beginning of these chunks
could be done, but would be almost silly, since the call would be right after the
code that acquires the locking.
Dec 2 2017
Modify the patch to not use atomic ops, which do not appear to be needed.
Add an inline comment related to nfsd thread locking.
Added inline reply to kib@'s comment.
Dec 1 2017
Nov 11 2017
Nov 9 2017
Nov 5 2017
Nov 4 2017
Nov 2 2017
Oct 25 2017
Oct 16 2017
Oct 15 2017
Oct 11 2017
Oct 10 2017
This variant of the patch sets the default # of threads to 8 * mp_ncpus instead of
a fixed 32. The sysctl allows a sysadmin to override this default.
Suggested by Julian Eischler.
The previous patch had a fundamental flaw, which was the code slept
waiting on completion of each RPC, serializing them.
This version of the patch doesn't sleep waiting for completion until
after all the RPCs have been started.
Oct 9 2017
Oct 8 2017
Oct 5 2017
Oct 4 2017
NFS part looks ok to me. (I might have used UINT32_MAX instead of 0xffffffff for NFS_MAX_LINK, but
that's a very minor nit..)
Oct 3 2017
I've accepted this. As bapt@ noted, it loses the alphabetical order.
I don't know if that matters. I believe it means that the reply to
"showmount -e" will not be alphabetically ordered. Does any
client care? I don't know.
Looks ok to me. I think the only effect is a change in the order of entries in the list
and I don't believe that matters.
Oct 2 2017
Oct 1 2017
Sep 29 2017
Sep 28 2017
Sep 27 2017
Sep 26 2017
Sep 24 2017
Sep 21 2017
Sep 19 2017
Sep 17 2017
Sep 4 2017
Sep 3 2017
Aug 25 2017
Aug 19 2017
This version looks fine to me.
Thanks for doing this, rick.
I've accepted this revision, but I do have one concern.
If a future code change resulted in the vnode lock changing from shared->exclusive
before the ncl_downgrade_vnlock(), it would erroneously do an unlock of this
- If you left ncl_upgrade_vnlock() returning oldlock and passed that into ncl_downgrade_lock() to use to decide whether or not to unlock the new lock, this would be avoided.