Hi NFS folks,
During our xfstests, we found generic/633 fails like:
============================================
FSTYP -- nfs
PLATFORM -- Linux/x86_64 btrfs 5.17.0-rc4-custom #236 SMP PREEMPT Sat Feb 19 15:09:03 CST 2022
MKFS_OPTIONS -- 127.0.0.1:/nfsscratch
MOUNT_OPTIONS -- -o vers=4 127.0.0.1:/nfsscratch /mnt/scratch
generic/633 0s ... [failed, exit status 1]- output mismatch (see /root/xfstests-dev/results//generic/633.out.bad)
--- tests/generic/633.out 2021-05-23 14:03:08.879999997 +0800
+++ /root/xfstests-dev/results//generic/633.out.bad 2022-02-19 16:31:28.660000013 +0800
@@ -1,2 +1,4 @@
QA output created by 633
Silence is golden
+idmapped-mounts.c: 7906: setgid_create - Success - failure: is_setgid
+idmapped-mounts.c: 13907: run_test - Success - failure: create operations in directories with setgid bit set
...
(Run 'diff -u /root/xfstests-dev/tests/generic/633.out /root/xfstests-dev/results//generic/633.out.bad' to see the entire diff)
Ran: generic/633
Failures: generic/633
Failed 1 of 1 tests
============================================
The failed test is about setgid inheritance.
When a file is created with S_ISGID in the directory with S_ISGID,
NFS doesn't strip the setgid bit of the new created file but others
(ext4/xfs/btrfs) do. They call inode_init_owner() which does
the strip after new_inode().
However, NFS has its own logical to handle inode capacities.
As the test says the behavior can be filesystem type specific,
I'd report to you NFS guys and ask whether it's a bug or not?
Thanks.
--
Su
