[LTP] [PATCH v2 2/5] fanotify21: Stop relying on exited child for pidfd error

[Petr Vorel]

> On Fri, Aug 28, 2026 at 3:39 PM Amir Goldstein <amir73il@gmail.com> wrote:

> > On Tue, Aug 25, 2026 at 12:36:09PM +0200, Petr Vorel wrote:
> > > Hi all,

> > > > fanotify21 used to verify the pidfd error case by generating an event
> > > > from a child process and reading the event after the child had exited.
> > > > This is no longer a stable way to trigger a pidfd error, because newer
> > > > kernels can report pidfds for exited event processes.

> > > > Read the event from a child process in a descendant PID namespace
> > > > instead. The reader cannot get the pidfd in the parent PID namespace
> > > > from fanotify, so pidfd creation will fail and the test can verify
> > > > FAN_NOPIDFD, or -ESRCH with FAN_REPORT_FD_ERROR.

> > > > Signed-off-by: AnonymeMeow <anonymemeow@gmail.com>
> > > > Reviewed-by: Jan Kara <jack@suse.cz>
> > > > Reviewed-by: Amir Goldstein <amir73il@gmail.com>

> > > ...
> > > >     /*
> > > > -    * Generate the event in either self or a child process. Event
> > > > -    * generation in a child process is done so that the FAN_NOPIDFD case
> > > > -    * can be verified.
> > > > +    * Read the event in either self or a child process in a descendant
> > > > +    * PID namespace. A reader in a descendant PID namespace cannot obtain
> > > > +    * the pidfd of the event process in the parent PID namespace so that
> > > > +    * the FAN_NOPIDFD case can be verified.
> > > >      */
> > > > -   if (tc->fork)
> > > > -           do_fork();
> > > > -   else
> > > > -           generate_event();
> > > > +   if (tc->want_pidfd_err && (reader_pid = SAFE_CLONE(&clone_args))) {
> > > nit: although I'd write it this way as well, checkpatch does not like this
> > > effective way :) (do not use assignment in if condition).

> > > > +           SAFE_WAITPID(reader_pid, &reader_exit_status, 0);
> > > > +           if (!WIFEXITED(reader_exit_status) || WEXITSTATUS(reader_exit_status))
> > > > +                   tst_brk(TBROK, "reader process exited incorrectly");

> > > nit: And the above should be probably replaced with tst_reap_children().

> > > But because I should have merged this long time ago to prevent false positive on
> > > 7.2, merging it now. Cleanup can be done later (together with using designated
> > > initializers).

> > > Merged the rest of the patch, thank you!


> > Hi Petr,

> > Sorry I did not have time to investigate and need to leave now
> > just wanted to let you know that test ends with failure exit code.
> > and does not seem to run with pretty recent rc7 kernel.

> > Is that expected?
> > Maybe it's something in my own test env.

> > Thanks,
> > Amir.

> > root@kvm-xfstests:~/ltp# ./fanotify/fanotify20 || echo FAIL
> > tst_tmpdir.c:308: TINFO: Using /tmp/LTP_fanTTAwH1 as tmpdir (tmpfs filesystem)
> > tst_kconfig.c:90: TINFO: Parsing kernel config '/proc/config.gz'
> > tst_kconfig.c:756: TINFO: CONFIG_PROVE_LOCKING kernel option detected which might slow the execution
> > tst_device.c:103: TINFO:[  787.367492] loop0: detected capacity change from 0 to 614400
> >  Found free device 0 '/dev/loop0'
> > tst_test.c:2048: TINFO: LTP version: 20260529-243-g9118a480c
> > tst_tes[  787.391529] /dev/zero: Can't lookup blockdev
> > t.c:2051: TINFO: Tested kernel: 7.2.0-rc7-xfstests-00008-g55d5763db1de #2982 SMP PREEMPT_DYNAMIC Thu Aug 27 12:04:04 CEST 2026 x86_64
> > tst_test.c:1876: TINFO: Overall timeout per run is 0h 02m 00s
> > tst_supported_fs_types.c:108: TINFO: Kernel supports ext2
> > tst_supported_fs_types.c:67: TINFO: mkfs.ext2 does exist
> > [  787.418143] /dev/zero: Can't lookup blockdev
> > tst_supported_fs_types.c:108: TINFO: Kernel supports ext3
> > tst_supported_fs_types.c:67: TINFO: mkfs.ext3 does exist
> > [  787.443657] /dev/zero: Can't lookup blockdev
> > tst_supported_fs_types.c:108: TINFO: Kernel supports ext4
> > tst_supported_fs_types.c:67: TINFO: m[  787.467489] /dev/zero: Can't lookup blockdev
> > kfs.ext4 does exist
> > tst_supported_fs_types.c:108: TINFO: Kernel supports xfs
> > tst_supported_fs_types.c:67: TINFO: mkfs.xfs does exist
> > tst_supported_fs_types.c:108: TINFO: Kernel supports btrfs
> > tst_supported_fs_types.c:67: TINFO: mkfs.btrfs does exist
> > tst_supported_fs_types.c:117: TINFO: Skipping bcachefs because of FUSE blacklist
> > [  787.521515] /dev/zero: Can't lookup blockdev
> > tst_supported_fs_types.c:108: TINFO: Kernel supports vfat
> > tst_supported_fs_types.c:67: TINFO: mkfs.vfat does exist
> > tst_supported_fs_types.c:140: TINFO: Filesystem exfat is not supported
> > tst_supported_fs_types.c:144: TINFO: FUSE does support ntfs
> > tst_supported_fs_types.c:63: TINFO: mkfs.ntfs does not exist
> > [  787.576420] /dev/zero: Can't lookup blockdev
> > tst_supported_fs_types.c:108: TINFO: Kernel supports ntfs3
> > tst_supported_fs_types.c:63: TINFO: mkfs.ntfs does not exist
> > tst_supported_fs_types.c:108: TINFO: Kernel supports tmpfs
> > tst_supported_fs_types.c:51: TINFO: mkfs is not needed for tmpfs
> > tst_test.c:1986: TINFO: === Testing on ext2 ===
> > fanotify20.c:51: TCONF: FAN_REPORT_PIDFD | FAN_REPORT_TID is supported since v7.2
> > tst_test.c:1986: TINFO: === Testing on ext3 ===
> > fanotify20.c:51: TCONF: FAN_REPORT_PIDFD | FAN_REPORT_TID is supported since v7.2
> > tst_test.c:1986: TINFO: === Testing on ext4 ===
> > fanotify20.c:51: TCONF: FAN_REPORT_PIDFD | FAN_REPORT_TID is supported since v7.2
> > tst_test.c:1986: TINFO: === Testing on xfs ===
> > fanotify20.c:51: TCONF: FAN_REPORT_PIDFD | FAN_REPORT_TID is supported since v7.2
> > tst_test.c:1986: TINFO: === Testing on btrfs ===
> > fanotify20.c:51: TCONF: FAN_REPORT_PIDFD | FAN_REPORT_TID is supported since v7.2
> > tst_test.c:1986: TINFO: === Testing on vfat ===
> > fanotify20.c:51: TCONF: FAN_REPORT_PIDFD | FAN_REPORT_TID is supported since v7.2
> > tst_test.c:1986: TINFO: === Testing on tmpfs ===
> > fanotify20.c:51: TCONF: FAN_REPORT_PIDFD | FAN_REPORT_TID is supported since v7.2

> > Summary:
> > passed   0
> > failed   0
> > broken   0
> > skipped  7
> > warnings 0

> > FAIL

> Ok. I see that TCONF for all returning non 0 is expected.

> Sorry for the noise.

No problem, thanks for your long term care of fanotify tests!

FYI we need to exit with non-zero exit code only to detect that something
was skipped (useful to notice).

Kind regards,
Petr

> Thanks,
> Amir.