summaryrefslogtreecommitdiffstats
path: root/net
diff options
context:
space:
mode:
authorAndrew Elble <aweits@rit.edu>2015-10-15 12:07:28 -0400
committerJ. Bruce Fields <bfields@redhat.com>2015-11-10 09:29:44 -0500
commit34ed9872e745fa56f10e9bef2cf3d2336c6c8816 (patch)
treef3e26b44fd4f97de1f2d9c82727c60dce8f8b925 /net
parent3e80dbcda7f3e1e349a779d7a14c0e08677c39fa (diff)
downloadop-kernel-dev-34ed9872e745fa56f10e9bef2cf3d2336c6c8816.zip
op-kernel-dev-34ed9872e745fa56f10e9bef2cf3d2336c6c8816.tar.gz
nfsd: eliminate sending duplicate and repeated delegations
We've observed the nfsd server in a state where there are multiple delegations on the same nfs4_file for the same client. The nfs client does attempt to DELEGRETURN these when they are presented to it - but apparently under some (unknown) circumstances the client does not manage to return all of them. This leads to the eventual attempt to CB_RECALL more than one delegation with the same nfs filehandle to the same client. The first recall will succeed, but the next recall will fail with NFS4ERR_BADHANDLE. This leads to the server having delegations on cl_revoked that the client has no way to FREE or DELEGRETURN, with resulting inability to recover. The state manager on the server will continually assert SEQ4_STATUS_RECALLABLE_STATE_REVOKED, and the state manager on the client will be looping unable to satisfy the server. List discussion also reports a race between OPEN and DELEGRETURN that will be avoided by only sending the delegation once to the client. This is also logically in accordance with RFC5561 9.1.1 and 10.2. So, let's: 1.) Not hand out duplicate delegations. 2.) Only send them to the client once. RFC 5561: 9.1.1: "Delegations and layouts, on the other hand, are not associated with a specific owner but are associated with the client as a whole (identified by a client ID)." 10.2: "...the stateid for a delegation is associated with a client ID and may be used on behalf of all the open-owners for the given client. A delegation is made to the client as a whole and not to any specific process or thread of control within it." Reported-by: Eric Meddaugh <etmsys@rit.edu> Cc: Trond Myklebust <trond.myklebust@primarydata.com> Cc: Olga Kornievskaia <aglo@umich.edu> Signed-off-by: Andrew Elble <aweits@rit.edu> Cc: stable@vger.kernel.org Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Diffstat (limited to 'net')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud