* interesting breakage in ltp fanotify10
@ 2025-06-22 21:51 Al Viro
2025-06-23 7:24 ` Amir Goldstein
0 siblings, 1 reply; 5+ messages in thread
From: Al Viro @ 2025-06-22 21:51 UTC (permalink / raw)
To: Amir Goldstein; +Cc: Eric Biggers, linux-fsdevel
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: interesting breakage in ltp fanotify10
2025-06-22 21:51 interesting breakage in ltp fanotify10 Al Viro
@ 2025-06-23 7:24 ` Amir Goldstein
2025-06-23 14:45 ` Al Viro
0 siblings, 1 reply; 5+ messages in thread
From: Amir Goldstein @ 2025-06-23 7:24 UTC (permalink / raw)
To: Al Viro; +Cc: Eric Biggers, linux-fsdevel, LTP List, Petr Vorel
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: interesting breakage in ltp fanotify10
2025-06-23 7:24 ` Amir Goldstein
@ 2025-06-23 14:45 ` Al Viro
2025-06-23 15:19 ` Amir Goldstein
0 siblings, 1 reply; 5+ messages in thread
From: Al Viro @ 2025-06-23 14:45 UTC (permalink / raw)
To: Amir Goldstein; +Cc: Eric Biggers, linux-fsdevel, LTP List, Petr Vorel
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>>>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: interesting breakage in ltp fanotify10
2025-06-23 14:45 ` Al Viro
@ 2025-06-23 15:19 ` Amir Goldstein
2025-06-23 15:38 ` Al Viro
0 siblings, 1 reply; 5+ messages in thread
From: Amir Goldstein @ 2025-06-23 15:19 UTC (permalink / raw)
To: Al Viro; +Cc: Eric Biggers, linux-fsdevel, LTP List, Petr Vorel
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: interesting breakage in ltp fanotify10
2025-06-23 15:19 ` Amir Goldstein
@ 2025-06-23 15:38 ` Al Viro
0 siblings, 0 replies; 5+ messages in thread
From: Al Viro @ 2025-06-23 15:38 UTC (permalink / raw)
To: Amir Goldstein; +Cc: Eric Biggers, linux-fsdevel, LTP List, Petr Vorel
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>
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2025-06-23 15:38 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-06-22 21:51 interesting breakage in ltp fanotify10 Al Viro
2025-06-23 7:24 ` Amir Goldstein
2025-06-23 14:45 ` Al Viro
2025-06-23 15:19 ` Amir Goldstein
2025-06-23 15:38 ` Al Viro
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox