2022-08-25 18:07:16

by Chuck Lever III

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

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

2022-08-25 18:44:00

by Trond Myklebust

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

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
[email protected]