From: Petr Vorel <pvorel@suse.cz>
To: Amir Goldstein <amir73il@gmail.com>
Cc: jack@suse.cz, ltp@lists.linux.it, AnonymeMeow <anonymemeow@gmail.com>
Subject: Re: [LTP] [PATCH v2 2/5] fanotify21: Stop relying on exited child for pidfd error
Date: Tue, 1 Sep 2026 14:10:18 +0200 [thread overview]
Message-ID: <20260901121018.GA862728@pevik> (raw)
In-Reply-To: <CAOQ4uxixsiz-0S6zBjnABNwxiGyThWOoMCKSUz-Pd_fo4WWyBA@mail.gmail.com>
> 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.
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2026-09-01 12:10 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-16 21:04 [LTP] [PATCH v2 0/5] fanotify: update pidfd tests for FAN_REPORT_TID AnonymeMeow
2026-06-16 21:04 ` [LTP] [PATCH v2 1/5] fanotify20: Skip FAN_REPORT_PIDFD | FAN_REPORT_TID test on v7.2+ AnonymeMeow
2026-06-17 7:37 ` [LTP] " linuxtestproject.agent
2026-07-28 13:53 ` Andrea Cervesato via ltp
2026-07-29 5:51 ` Andrea Cervesato via ltp
2026-07-29 8:42 ` Petr Vorel
2026-06-17 15:33 ` [LTP] [PATCH v2 1/5] " Jan Kara
2026-08-17 4:51 ` Petr Vorel
2026-06-16 21:04 ` [LTP] [PATCH v2 2/5] fanotify21: Stop relying on exited child for pidfd error AnonymeMeow
2026-08-25 10:36 ` Petr Vorel
2026-08-28 13:39 ` Amir Goldstein
2026-08-29 17:46 ` Amir Goldstein
2026-09-01 12:10 ` Petr Vorel [this message]
2026-06-16 21:04 ` [LTP] [PATCH v2 3/5] fanotify21: Simplify read_pidfd_fdinfo() AnonymeMeow
2026-06-16 21:04 ` [LTP] [PATCH v2 4/5] fanotify21: Add test variants for FAN_REPORT_TID AnonymeMeow
2026-06-16 21:04 ` [LTP] [PATCH v2 5/5] fanotify21: Add FAN_REPORT_TID pidfd coverage AnonymeMeow
2026-06-17 15:04 ` Jan Kara
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260901121018.GA862728@pevik \
--to=pvorel@suse.cz \
--cc=amir73il@gmail.com \
--cc=anonymemeow@gmail.com \
--cc=jack@suse.cz \
--cc=ltp@lists.linux.it \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox