Bug 998024 - nfsd sometimes grants delegations too soon following conflicting open requests
nfsd sometimes grants delegations too soon following conflicting open requests
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: kernel (Show other bugs)
All Linux
medium Severity medium
: rc
: ---
Assigned To: J. Bruce Fields
Depends On:
Blocks: 994246 1056239 1111227
  Show dependency treegraph
Reported: 2013-08-16 14:48 EDT by Scott Mayhew
Modified: 2014-10-14 01:22 EDT (History)
8 users (show)

See Also:
Fixed In Version: kernel-2.6.32-489.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1111227 (view as bug list)
Last Closed: 2014-10-14 01:22:32 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 420183 None None None Never

  None (edit)
Description Scott Mayhew 2013-08-16 14:48:37 EDT
Description of problem:
nfsd sometimes grants delegations too soon following conflicting open requests

Version-Release number of selected component (if applicable):

How reproducible:
Easily reproducible.

Steps to Reproduce:
Client 1:

1. open a file and leave it open (ensures we already have some state
established on the server when it's deciding whether to grant us a
# vi /mnt/file1

2. switch to another terminal window and run the following
# touch /mnt/file2
# while :; do cat /mnt/file2; done
Client 1 gets a read delegation on in the OPEN reply for file2 in the
above command.

Client 2:
# date >> /mnt/file2

Actual results:
The command on client 2 never finishes.  What the server returns
NFS4ERR_DELAY to client 2 and recalls the delegation from client 1.
Client 1 returns the delegation to the server and immediately sends a
new OPEN, for which the server grants it another read delegation.  This
happens before client 2 "retries" the OPEN, so it's just going to wind
up getting NFS4ERR_DELAY again.

Expected results:
Client 2 should be able to open the file for writing after returning from its delay before Client 1 is granted another read delegation.

Additional info:
nfsd does currently track track the fact that there was a conflicting open via the nfs4_file->fi_had_conflict field... the problem is that the nfs4_file goes away when the reference count goes to zero.
Comment 10 J. Bruce Fields 2014-06-18 17:29:18 EDT
Note Neil Brown fixed this with 6282cd565553 "NFSD: Don't hand out delegations for 30 seconds after recalling them.", soon to be upstream.
Comment 13 Rafael Aquini 2014-07-07 22:19:19 EDT
Patch(es) available on kernel-2.6.32-489.el6
Comment 22 errata-xmlrpc 2014-10-14 01:22:32 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.