Bug 1563592 - pynfs::nfs4.1 SEQ9 test fail
Summary: pynfs::nfs4.1 SEQ9 test fail
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 27
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-04-04 09:13 UTC by JianHong Yin
Modified: 2018-04-10 19:46 UTC (History)
20 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-04-10 19:46:45 UTC
Type: Bug


Attachments (Terms of Use)

Description JianHong Yin 2018-04-04 09:13:39 UTC
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

Comment 1 Laura Abbott 2018-04-04 16:14:03 UTC
Did these ever work on an earlier version of Fedora?

Comment 2 Laura Abbott 2018-04-06 02:36:35 UTC
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.

Comment 3 J. Bruce Fields 2018-04-10 19:46:45 UTC
(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.


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