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

[Amir Goldstein]

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.

Thanks,
Amir.