interesting breakage in ltp fanotify10

interesting breakage in ltp fanotify10

[Al Viro]

	LTP 6763a3650734 "syscalls/fanotify10: Add test cases for evictable
ignore mark" has an interesting effect on boxen where FANOTIFY is not
enabled.  The thing is, tst_brk() ends up calling ->cleanup().  See the
problem?
	SAFE_FILE_PRINTF(CACHE_PRESSURE_FILE, "%d", old_cache_pressure);
is executed, even though
	SAFE_FILE_SCANF(CACHE_PRESSURE_FILE, "%d", &old_cache_pressure);
	/* Set high priority for evicting inodes */
	SAFE_FILE_PRINTF(CACHE_PRESSURE_FILE, "500");
hadn't been.

	Result: fanotify10 on such kernel configs ends up zeroing
/proc/sys/vm/vfs_cache_pressure.  How much does it confuse the rest of
LTP is an interesting question; it *does* have a fun effect on subsequent
xfstests run - generic/622 gets confused.  No other failures get reported
by xfstests, for whatever little it's worth...

	Arguably, there's an xfstests bug as well - since generic/622
depends upon vfs_cache_pressure being non-zero, it ought to set it
to something sane.

Re: interesting breakage in ltp fanotify10

[Amir Goldstein]

On Sun, Jun 22, 2025 at 11:51 PM Al Viro <viro@zeniv.linux.org.uk> wrote:
>
>         LTP 6763a3650734 "syscalls/fanotify10: Add test cases for evictable
> ignore mark" has an interesting effect on boxen where FANOTIFY is not
> enabled.  The thing is, tst_brk() ends up calling ->cleanup().  See the
> problem?
>         SAFE_FILE_PRINTF(CACHE_PRESSURE_FILE, "%d", old_cache_pressure);
> is executed, even though
>         SAFE_FILE_SCANF(CACHE_PRESSURE_FILE, "%d", &old_cache_pressure);
>         /* Set high priority for evicting inodes */
>         SAFE_FILE_PRINTF(CACHE_PRESSURE_FILE, "500");
> hadn't been.
>
>         Result: fanotify10 on such kernel configs ends up zeroing
> /proc/sys/vm/vfs_cache_pressure.

oops.
strange enough, I cannot reproduce it as something is preventing
zeroing vfs_cache_pressure:

fanotify23.c:232: TCONF: fanotify not configured in kernel
fanotify23.c:249: TWARN: Failed to close FILE
'/proc/sys/vm/vfs_cache_pressure': EINVAL (22)

# cat /proc/sys/vm/vfs_cache_pressure
100

But I'll send a fix all the same.

Thanks,
Amir.

Re: interesting breakage in ltp fanotify10

[Al Viro]

On Mon, Jun 23, 2025 at 09:24:22AM +0200, Amir Goldstein wrote:
> On Sun, Jun 22, 2025 at 11:51 PM Al Viro <viro@zeniv.linux.org.uk> wrote:
> >
> >         LTP 6763a3650734 "syscalls/fanotify10: Add test cases for evictable
> > ignore mark" has an interesting effect on boxen where FANOTIFY is not
> > enabled.  The thing is, tst_brk() ends up calling ->cleanup().  See the
> > problem?
> >         SAFE_FILE_PRINTF(CACHE_PRESSURE_FILE, "%d", old_cache_pressure);
> > is executed, even though
> >         SAFE_FILE_SCANF(CACHE_PRESSURE_FILE, "%d", &old_cache_pressure);
> >         /* Set high priority for evicting inodes */
> >         SAFE_FILE_PRINTF(CACHE_PRESSURE_FILE, "500");
> > hadn't been.
> >
> >         Result: fanotify10 on such kernel configs ends up zeroing
> > /proc/sys/vm/vfs_cache_pressure.
> 
> oops.
> strange enough, I cannot reproduce it as something is preventing
> zeroing vfs_cache_pressure:
> 
> fanotify23.c:232: TCONF: fanotify not configured in kernel
> fanotify23.c:249: TWARN: Failed to close FILE
> '/proc/sys/vm/vfs_cache_pressure': EINVAL (22)

How old is your ltp tree?  Mine was from late May (81d460ba6737 "overcommit_memory:
Disable optimization for malloc to prevent false positives") and I'm definitely 
seeing that behaviour with fanotify23 as well.  No TWARN, though -
cmdline="fanotify23"
contacts=""
analysis=exit
<<<test_output>>>
tst_tmpdir.c:316: TINFO: Using /tmp/ltp-sIG1rbZMcQ/LTP_fan7Qw3GC as tmpdir (ext2/ext3/ext4 filesystem)
tst_device.c:98: TINFO: Found free device 0 '/dev/loop0'
tst_test.c:1216: TINFO: Formatting /dev/loop0 with ext2 opts='' extra opts=''
mke2fs 1.47.2 (1-Jan-2025)
tst_test.c:1228: TINFO: Mounting /dev/loop0 to /tmp/ltp-sIG1rbZMcQ/LTP_fan7Qw3GC/fs_mnt fstyp=ext2 flags=0
tst_test.c:1952: TINFO: LTP version: 20250130-274-g81d460ba6
tst_test.c:1955: TINFO: Tested kernel: 6.16.0-rc3+ #32 SMP PREEMPT_DYNAMIC Sun Jun 22 19:06:57 EDT 2025 x86_64
tst_kconfig.c:88: TINFO: Parsing kernel config '/boot/config-6.16.0-rc3+'
tst_test.c:1773: TINFO: Overall timeout per run is 0h 00m 30s
fanotify.h:175: TCONF: fanotify not configured in kernel

Summary:
passed   0
failed   0
broken   0
skipped  1
warnings 0
incrementing stop
<<<execution_status>>>
initiation_status="ok"
duration=1 termination_type=exited termination_id=32 corefile=no
cutime=0 cstime=1
<<<test_end>>>

Re: interesting breakage in ltp fanotify10

[Amir Goldstein]

On Mon, Jun 23, 2025 at 4:45 PM Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> On Mon, Jun 23, 2025 at 09:24:22AM +0200, Amir Goldstein wrote:
> > On Sun, Jun 22, 2025 at 11:51 PM Al Viro <viro@zeniv.linux.org.uk> wrote:
> > >
> > >         LTP 6763a3650734 "syscalls/fanotify10: Add test cases for evictable
> > > ignore mark" has an interesting effect on boxen where FANOTIFY is not
> > > enabled.  The thing is, tst_brk() ends up calling ->cleanup().  See the
> > > problem?
> > >         SAFE_FILE_PRINTF(CACHE_PRESSURE_FILE, "%d", old_cache_pressure);
> > > is executed, even though
> > >         SAFE_FILE_SCANF(CACHE_PRESSURE_FILE, "%d", &old_cache_pressure);
> > >         /* Set high priority for evicting inodes */
> > >         SAFE_FILE_PRINTF(CACHE_PRESSURE_FILE, "500");
> > > hadn't been.
> > >
> > >         Result: fanotify10 on such kernel configs ends up zeroing
> > > /proc/sys/vm/vfs_cache_pressure.
> >
> > oops.
> > strange enough, I cannot reproduce it as something is preventing
> > zeroing vfs_cache_pressure:
> >
> > fanotify23.c:232: TCONF: fanotify not configured in kernel
> > fanotify23.c:249: TWARN: Failed to close FILE
> > '/proc/sys/vm/vfs_cache_pressure': EINVAL (22)
>
> How old is your ltp tree?  Mine was from late May (81d460ba6737 "overcommit_memory:
> Disable optimization for malloc to prevent false positives")

My LTP tree is from end of May tag 20250530

> and I'm definitely
> seeing that behaviour with fanotify23 as well.  No TWARN, though -

I have no idea where this strange TWARN is coming from
I did not investigate it, but the bug is there anyway, so I sent a fix.

Thanks,
Amir.

Re: interesting breakage in ltp fanotify10

[Al Viro]

On Mon, Jun 23, 2025 at 05:19:26PM +0200, Amir Goldstein wrote:

> I have no idea where this strange TWARN is coming from
> I did not investigate it, but the bug is there anyway, so I sent a fix.

OK...  Current LTP + patch you've posted does not screw that sysctl
anymore, so...  Tested-by: Al Viro <viro@zeniv.linux.org.uk>