Re: lots of fstests cases fail on overlay with util-linux 2.40.2 (new mount APIs)

[Ian Kent <raven@themaw.net>]

On 29/10/24 07:13, Dave Chinner wrote:
> On Tue, Oct 29, 2024 at 03:28:04AM +0800, Zorro Lang wrote:
>> On Mon, Oct 28, 2024 at 01:22:52PM +0100, Christian Brauner wrote:
>>> On Sun, Oct 27, 2024 at 02:07:41AM +0800, Zorro Lang wrote:
>>>> Hi,
>>>>
>>>> Recently, I hit lots of fstests cases fail on overlayfs (xfs underlying, no
>>>> specific mount options), e.g.
>>>>
>>>> FSTYP         -- overlay
>>>> PLATFORM      -- Linux/s390x s390x-xxxx 6.12.0-rc4+ #1 SMP Fri Oct 25 14:29:18 EDT 2024
>>>> MKFS_OPTIONS  -- -m crc=1,finobt=1,rmapbt=0,reflink=1,inobtcount=1,bigtime=1 /mnt/fstests/SCRATCH_DIR
>>>> MOUNT_OPTIONS -- -o context=system_u:object_r:root_t:s0 /mnt/fstests/SCRATCH_DIR /mnt/fstests/SCRATCH_DIR/ovl-mnt
>>>>
>>>> generic/294       [failed, exit status 1]- output mismatch (see /var/lib/xfstests/results//generic/294.out.bad)
>>>>      --- tests/generic/294.out	2024-10-25 14:38:32.098692473 -0400
>>>>      +++ /var/lib/xfstests/results//generic/294.out.bad	2024-10-25 15:02:34.698605062 -0400
>>>>      @@ -1,5 +1,5 @@
>>>>       QA output created by 294
>>>>      -mknod: SCRATCH_MNT/294.test/testnode: File exists
>>>>      -mkdir: cannot create directory 'SCRATCH_MNT/294.test/testdir': File exists
>>>>      -touch: cannot touch 'SCRATCH_MNT/294.test/testtarget': Read-only file system
>>>>      -ln: creating symbolic link 'SCRATCH_MNT/294.test/testlink': File exists
>>>>      +mount: /mnt/fstests/SCRATCH_DIR/ovl-mnt: fsconfig system call failed: overlay: No changes allowed in reconfigure.
>>>>      +       dmesg(1) may have more information after failed mount system call.
>>> In the new mount api overlayfs has been changed to reject invalid mount
>>> option on remount whereas in the old mount api we just igorned them.
>> Not only g/294 fails on new mount utils, not sure if all of them are from same issue.
>> If you need, I can paste all test failures (only from my side) at here.
>>
>>> If this a big problem then we need to change overlayfs to continue
>>> ignoring garbage mount options passed to it during remount.
>> Do you mean this behavior change is only for overlayfs, doesn't affect other fs?
> We tried this with XFS years ago, and reverted back to the old
> behaviour of silently ignoring mount options we don't support in
> remount. The filesystem code has no idea what mount API
> userspace is using for remount - it can't assume that it is ok to
> error out on unknown/unsupported options because it uses
> the fsreconfigure API internally....

I expect that remounting to change options for overlayfs has very 
limited use

cases. Perhaps remounting (the upper layer) read-only is useful ...


The problem here is that xfstests wants to remount the mount read-only 
in this

test which has never actually been done so xfstests reporting a failure 
has no

value!


Ian