Is generic/426 failing on NFS for anyone else?

Is generic/426 failing on NFS for anyone else?

[Chuck Lever III]

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().


--
Chuck Lever

Re: Is generic/426 failing on NFS for anyone else?

[Trond Myklebust]

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@hammerspace.com