Hide Forgot
Description of problem: As Summary: run pynfs test on Fedora, got these new failure: SEQ9a st_sequence.testReplayCache001 : FAILURE OP_SEQUENCE should return NFS4_OK, instead got NFS4ERR_SEQ_FALSE_RETRY SEQ9b st_sequence.testReplayCache002 : FAILURE OP_SEQUENCE should return NFS4_OK, instead got NFS4ERR_SEQ_FALSE_RETRY SEQ9c st_sequence.testReplayCache003 : FAILURE OP_SEQUENCE should return NFS4ERR_INVAL, instead got NFS4ERR_SEQ_FALSE_RETRY SEQ9d st_sequence.testReplayCache004 : FAILURE OP_SEQUENCE should return NFS4ERR_INVAL, instead got NFS4ERR_SEQ_FALSE_RETRY SEQ9e st_sequence.testReplayCache005 : FAILURE OP_SEQUENCE should return NFS4ERR_OP_ILLEGAL, instead got NFS4ERR_SEQ_FALSE_RETRY SEQ9f st_sequence.testReplayCache006 : PASS Version-Release number of selected component (if applicable): Fedora-27 kernel-4.15.14-300.fc27 nfs-utils-2.2.1-4.rc2.fc27 How reproducible: always Steps to Reproduce: ''' # git clone git://git.linux-nfs.org/projects/bfields/pynfs.git # (cd pynfs; python setup.py install) # cd pynfs/nfs4.1 # ./testserver.py --outfile test.log --maketree $nfsshare all &>std.log # #check std.log and test.log Actual results: SEQ9a st_sequence.testReplayCache001 : FAILURE OP_SEQUENCE should return NFS4_OK, instead got NFS4ERR_SEQ_FALSE_RETRY SEQ9b st_sequence.testReplayCache002 : FAILURE OP_SEQUENCE should return NFS4_OK, instead got NFS4ERR_SEQ_FALSE_RETRY SEQ9c st_sequence.testReplayCache003 : FAILURE OP_SEQUENCE should return NFS4ERR_INVAL, instead got NFS4ERR_SEQ_FALSE_RETRY SEQ9d st_sequence.testReplayCache004 : FAILURE OP_SEQUENCE should return NFS4ERR_INVAL, instead got NFS4ERR_SEQ_FALSE_RETRY SEQ9e st_sequence.testReplayCache005 : FAILURE OP_SEQUENCE should return NFS4ERR_OP_ILLEGAL, instead got NFS4ERR_SEQ_FALSE_RETRY Expected results: no these failure Additional info: there is no SEQ9 failure on RHEL-7
Did these ever work on an earlier version of Fedora?
This seems to be caused by commit 53da6a53e1d414e05759fa59b7032ee08f4e22d7 Author: J. Bruce Fields <bfields@redhat.com> Date: Tue Oct 17 20:38:49 2017 -0400 nfsd4: catch some false session retries The spec allows us to return NFS4ERR_SEQ_FALSE_RETRY if we notice that the client is making a call that matches a previous (slot, seqid) pair but that *isn't* actually a replay, because some detail of the call doesn't actually match the previous one. Catching every such case is difficult, but we may as well catch a few easy ones. This also handles the case described in the previous patch, in a different way. The spec does however require us to catch the case where the difference is in the rpc credentials. This prevents somebody from snooping another user's replies by fabricating retries. (But the practical value of the attack is limited by the fact that the replies with the most sensitive data are READ replies, which are not normally cached.) Tested-by: Olga Kornievskaia <aglo@umich.edu> Signed-off-by: J. Bruce Fields <bfields@redhat.com> I'm pretty sure this is a test case bug because if you look at the test case, the value of cache_this isn't the same. http://git.linux-nfs.org/?p=bfields/pynfs41.git;a=blob;f=nfs4.1/server41tests/st_sequence.py;h=f0089551ba3cc499b925534d082070925dfd4562;hb=refs/heads/master#l108 If you change it the test passes. The tests need to be fixed.
(In reply to Laura Abbott from comment #2) > If you change it the test passes. The tests need to be fixed. Indeed, the tests are wrong. Tom Haynes actually sent a patch for this back in October, it prompted a digression on correct server behavior in these cases, and I dropped the original patch. It does the obvious thing and just sets cache_this=True on both calls, which I think is what was originally intended. I've applied his patch and pushed out the result to git://linux-nfs.org/~bfields/pynfs.git So, this is NOTABUG for knfsd.