On Thu, 2022-08-25 at 17:52 +0000, Chuck Lever III wrote: > I have started to see this failure with some regularity: > > [cel@morisot xfstests]$ sudo ./check -nfs generic/426 > FSTYP -- nfs > PLATFORM -- Linux/x86_64 morisot 6.0.0-rc1-00001-g2d8cdadac0d6 > #132 SMP PREEMPT Sun Aug 21 19:30:12 EDT 2022 > > generic/426 2s ... - output mismatch (see > /home/cel/src/xfstests/results//generic/426.out.bad) > --- tests/generic/426.out 2018-03-10 11:11:33.483657919 -0500 > +++ /home/cel/src/xfstests/results//generic/426.out.bad 2022- > 08-25 13:40:01.174779476 -0400 > @@ -1,5 +1,3077 @@ > QA output created by 426 > test_file_handles TEST_DIR/426-dir -d > test_file_handles TEST_DIR/426-dir > +open_by_handle(/mnt/426-dir/file000000) returned 116 incorrectly > on a linked file! > +open_by_handle(/mnt/426-dir/file000001) returned 116 incorrectly > on a linked file! > +open_by_handle(/mnt/426-dir/file000002) returned 116 incorrectly > on a linked file! > +open_by_handle(/mnt/426-dir/file000003) returned 116 incorrectly > on a linked file! > ... > (Run 'diff -u /home/cel/src/xfstests/tests/generic/426.out > /home/cel/src/xfstests/results//generic/426.out.bad' to see the > entire diff) > Ran: generic/426 > Failures: generic/426 > Failed 1 of 1 tests > > [cel@morisot xfstests]$ > > 116 is ESTALE. > > During this test (on NFSv4.0) the client sends an OPEN(CLAIM_NULL) > with > a name of "/" (confirmed via network capture). The Linux NFS server > rejects this OPEN with NFS4ERR_BADNAME due to a check in > fs/nfsd/nfs4xdr.c::check_filename(). > There is no sane way to support open_by_handle() in NFSv4.0, due to the protocol limitations on OP_OPEN so we should just fix the client to return ENOTSUP if someone tries. -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@xxxxxxxxxxxxxxx
