Bug #58054
closed
kclient: xfstests-dev generic/684 fails
Added by Xiubo Li over 1 year ago.
Updated about 1 year ago.
Description
generic/684 - output mismatch (see /data/xfstests-dev/results//generic/684.out.bad)
--- tests/generic/684.out 2022-06-08 16:30:24.648434802 +0800
+++ /data/xfstests-dev/results//generic/684.out.bad 2022-11-18 05:43:36.212526827 +0800
@@ -1,19 +1,19 @@
QA output created by 684
Test 1 - qa_user, non-exec file fpunch
6666 -rwSrwSrw- TEST_DIR/684/a
-666 -rw-rw-rw- TEST_DIR/684/a
+6666 -rwSrwSrw- TEST_DIR/684/a
Test 2 - qa_user, group-exec file fpunch
...
(Run 'diff -u /data/xfstests-dev/tests/generic/684.out /data/xfstests-dev/results//generic/684.out.bad' to see the entire diff)
- Description updated (diff)
- Status changed from New to In Progress
Kernel ceph client doesn't clear the suid/sgid, but the kernel fuse has done that, so the ceph-fuse client.
There's not a Posix item describes that we should clear the suid/sgid in fallocate, but this the default behavior of most fs in linux and even in vfs layer.
And there are generic tests in xfstests-dev to test this.
To make ceph clients I will fix this in kclient and libcephfs.
- Copied to Feature #58680: libcephfs: clear the suid/sgid for fallocate added
There is another problem, which is the time stamps is not updated too after fallocate. This should be fixed at the same time.
The ceph patchwork link: https://patchwork.kernel.org/project/ceph-devel/patch/20230213112834.15714-1-xiubli@redhat.com/
[root@lxbceph1 xfstests-dev]# ./check generic/684
FSTYP -- ceph
PLATFORM -- Linux/x86_64 lxbceph1 6.2.0-rc6+ #208 SMP PREEMPT_DYNAMIC Mon Feb 13 09:30:30 CST 2023
MKFS_OPTIONS -- 10.72.47.117:40747:/testB
MOUNT_OPTIONS -- -o name=admin,nowsync,copyfrom,rasize=4096 -o context=system_u:object_r:root_t:s0 10.72.47.117:40747:/testB /mnt/kcephfs.B
generic/684 208s ... 169s
Ran: generic/684
Passed all 1 tests
- Status changed from In Progress to Fix Under Review
The following is from Jeff's comments in the patch:
Actually, posix_fallocate doesn't do hole punching. It just ensures that
blocks are reserved to back future writes. Given that that's not
something "observable" and won't change the contents of the file, then
there really is no need to change the times and clear set{u,g}id bits
there.
Linux' fallocate is different. It's a GNU API not covered by POSIX, and
can result in an observable change to the contents of the file. There,
we _must_ clear the setuid/setgid bits and update timestamps, at least
in the cases where the content can change.
Thanks Jeff.
- Status changed from Fix Under Review to Resolved
Also available in: Atom
PDF