Linux filesystem development
 help / color / mirror / Atom feed
From: AnonymeMeow <anonymemeow@gmail.com>
To: brauner@kernel.org
Cc: amir73il@gmail.com, jack@suse.cz, repnop@google.com,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	AnonymeMeow <anonymemeow@gmail.com>
Subject: [PATCH v2] fanotify: report thread pidfds for FAN_REPORT_TID
Date: Fri, 29 May 2026 10:00:35 +0800	[thread overview]
Message-ID: <20260529020035.17477-1-anonymemeow@gmail.com> (raw)
In-Reply-To: <20260528-schmuckvoll-heilen-garen-be77b4208671@brauner>

The FAN_REPORT_PIDFD and FAN_REPORT_TID flags used to be mutually
exclusive because by the time the pidfd support was introduced to
fanotify, pidfds could only be created for thread group leaders. Now
that the pidfd API supports thread-specific pidfds via PIDFD_THREAD,
this restriction can be lifted.

Also drop the pid_has_task() check to allow pidfds to be reported for
reaped tasks as well.

Link: https://lore.kernel.org/lkml/20260528-schmuckvoll-heilen-garen-be77b4208671@brauner/
Signed-off-by: AnonymeMeow <anonymemeow@gmail.com>
---

On 2026-05-28 13:51 +0200, Christian Brauner wrote:
> For quite a while the kernel refused to hand out pidfds for reaped
> processes even if the struct pid was pinned like in this case.
> 
> But that makes various APIs - including this one - way less powerful
> than they can be. Nowadays the socket layer already hands out pidfds for
> reaped processes. It also stashed the struct pid. Let's do the same
> here.
> 
> Drop the pid_has_task() change and then:
> 
> pidfd = pidfd_prepare(event->pid, pidfd_flags | PIDFD_STALE, &pidfd_file);
> 
> which instructs pidfs to and out a pidfd even if the task has already
> been reaped. Reaped pidfds can still be queried for various types of
> information that is kept around even if the task is long gone.

Thanks for the review. I've updated this in v2 as you suggested.

Also, the LTP fanotify21 test currently explicitly expects ESRCH or
FAN_NOPIDFD for exited processes. I will update that test case accordingly.

With Best Regards,
AnonymeMeow

---
 fs/notify/fanotify/fanotify_user.c | 33 +++++++-----------------------
 1 file changed, 7 insertions(+), 26 deletions(-)

diff --git a/fs/notify/fanotify/fanotify_user.c b/fs/notify/fanotify/fanotify_user.c
index ae904451dfc0..b604e3da58ad 100644
--- a/fs/notify/fanotify/fanotify_user.c
+++ b/fs/notify/fanotify/fanotify_user.c
@@ -19,6 +19,7 @@
 #include <linux/memcontrol.h>
 #include <linux/statfs.h>
 #include <linux/exportfs.h>
+#include <linux/pidfd.h>
 
 #include <asm/ioctls.h>
 
@@ -903,25 +904,13 @@ static ssize_t copy_event_to_user(struct fsnotify_group *group,
 		metadata.fd = fd >= 0 ? fd : FAN_NOFD;
 
 	if (pidfd_mode) {
-		/*
-		 * Complain if the FAN_REPORT_PIDFD and FAN_REPORT_TID mutual
-		 * exclusion is ever lifted. At the time of incoporating pidfd
-		 * support within fanotify, the pidfd API only supported the
-		 * creation of pidfds for thread-group leaders.
-		 */
-		WARN_ON_ONCE(FAN_GROUP_FLAG(group, FAN_REPORT_TID));
+		unsigned int pidfd_flags = PIDFD_STALE;
 
-		/*
-		 * The PIDTYPE_TGID check for an event->pid is performed
-		 * preemptively in an attempt to catch out cases where the event
-		 * listener reads events after the event generating process has
-		 * already terminated.  Depending on flag FAN_REPORT_FD_ERROR,
-		 * report either -ESRCH or FAN_NOPIDFD to the event listener in
-		 * those cases with all other pidfd creation errors reported as
-		 * the error code itself or as FAN_EPIDFD.
-		 */
-		if (metadata.pid && pid_has_task(event->pid, PIDTYPE_TGID))
-			pidfd = pidfd_prepare(event->pid, 0, &pidfd_file);
+		if (FAN_GROUP_FLAG(group, FAN_REPORT_TID))
+			pidfd_flags |= PIDFD_THREAD;
+
+		if (metadata.pid)
+			pidfd = pidfd_prepare(event->pid, pidfd_flags, &pidfd_file);
 
 		if (!FAN_GROUP_FLAG(group, FAN_REPORT_FD_ERROR) && pidfd < 0)
 			pidfd = pidfd == -ESRCH ? FAN_NOPIDFD : FAN_EPIDFD;
@@ -1628,14 +1617,6 @@ SYSCALL_DEFINE2(fanotify_init, unsigned int, flags, unsigned int, event_f_flags)
 #endif
 		return -EINVAL;
 
-	/*
-	 * A pidfd can only be returned for a thread-group leader; thus
-	 * FAN_REPORT_PIDFD and FAN_REPORT_TID need to remain mutually
-	 * exclusive.
-	 */
-	if ((flags & FAN_REPORT_PIDFD) && (flags & FAN_REPORT_TID))
-		return -EINVAL;
-
 	/* Don't allow mixing mnt events with inode events for now */
 	if (flags & FAN_REPORT_MNT) {
 		if (class != FAN_CLASS_NOTIF)
-- 
2.54.0


  reply	other threads:[~2026-05-29  2:01 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-24 10:24 [PATCH] fanotify: report thread pidfds for FAN_REPORT_TID AnonymeMeow
2026-05-25 10:04 ` Amir Goldstein
2026-05-27  6:40   ` [PATCH] fanotify: prepare tests for thread pidfd reporting AnonymeMeow
2026-05-27  7:23     ` Petr Vorel
2026-05-27 19:50       ` [PATCH v2 1/2] fanotify: fix crash when running multiple iterations AnonymeMeow
2026-05-27 19:50         ` [PATCH v2 2/2] fanotify: prepare tests for thread pidfd reporting AnonymeMeow
2026-05-28 11:51 ` [PATCH] fanotify: report thread pidfds for FAN_REPORT_TID Christian Brauner
2026-05-29  2:00   ` AnonymeMeow [this message]
2026-05-29  7:21     ` [PATCH v2] " Amir Goldstein
2026-05-29  7:39       ` Christian Brauner
2026-05-29 10:32         ` Amir Goldstein
2026-06-01  9:12       ` 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=20260529020035.17477-1-anonymemeow@gmail.com \
    --to=anonymemeow@gmail.com \
    --cc=amir73il@gmail.com \
    --cc=brauner@kernel.org \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=repnop@google.com \
    /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