• Chuck Lever's avatar
    NFS: NFSv4 readdir loses entries · d1205f87
    Chuck Lever authored
    On recent 2.6.38-rc kernels, connectathon basic test 6 fails on
    NFSv4 mounts of OpenSolaris with something like:
    
    > ./test6: readdir
    > 	./test6: (/mnt/klimt/matisse.test) didn't read expected 'file.12' dir entry, pass 0
    > 	./test6: (/mnt/klimt/matisse.test) didn't read expected 'file.82' dir entry, pass 0
    > 	./test6: (/mnt/klimt/matisse.test) didn't read expected 'file.164' dir entry, pass 0
    > 	./test6: (/mnt/klimt/matisse.test) Test failed with 3 errors
    > basic tests failed
    > Tests failed, leaving /mnt/klimt mounted
    > [cel@matisse cthon04]$
    
    I narrowed the problem down to nfs4_decode_dirent() reporting that the
    decode buffer had overflowed while decoding the entries for those
    missing files.
    
    verify_attr_len() assumes both it's pointer arguments reside on the
    same page.  When these arguments point to locations on two different
    pages, verify_attr_len() can report false errors.  This can happen now
    that a large NFSv4 readdir result can span pages.
    
    We have reasonably good checking in nfs4_decode_dirent() anyway, so
    it should be safe to simply remove the extra checking.
    
    At a guess, this was introduced by commit 6650239a, "NFS: Don't use
    vm_map_ram() in readdir".
    
    Cc: stable@kernel.org [2.6.37]
    Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
    Signed-off-by: default avatarTrond Myklebust <Trond.Myklebust@netapp.com>
    d1205f87
nfs4xdr.c 163 KB