Frank Filz has uploaded this change for review.
Cleanup handling of SEQUENCE - particularly do not hold slot_lock
Since a COMPOUND may be suspended, and resumed by a different thread,
we must not hold the slot_lock mutex. Instead of holding it, we set an
in_use flag in the slot.
If we receive a SEQUENCE op and in_use is true, then we have an op
that was submitted while we are still processing. If it's a replay,
then RFC 8881 suggests using NFS4ERR_DELAY which will tell the client
to delay and retry at which point hopefully the original op has now
completed. Othwerwise, it's a sequence error, so just immediately
return that.
Several bits of code are simplified to reflect conditions that must be
true.
compound_data cached_result_status is removed because the status is
available from the cached response (also gets rid of an ugly line of
code).
Also, we don't set cd_slot unless this COMPOUND is proceeding, so
there is no later confusion.
Because of all of these conditions, we don't actually need to hold the
slot_lock to update the slot cache (no other thread will access it
because of the in_use flag).
Several comments are expanded to more clearly document what is
occuring.
Change-Id: I5a2bdc1d6a8013bc27c8b24493aeb30647c480ac
Signed-off-by: Frank S. Filz <ffilzlnx@mindspring.com>
---
M src/Protocols/NFS/nfs4_Compound.c
M src/Protocols/NFS/nfs4_op_sequence.c
M src/include/nfs_proto_data.h
M src/include/sal_data.h
4 files changed, 100 insertions(+), 37 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/13/1258513/1
To view, visit change 1258513. To unsubscribe, or for help writing mail filters, visit settings.