[PATCH v3 0/2] fanotify: lift pidfd reporting restrictions

[PATCH v3 0/2] fanotify: lift pidfd reporting restrictions

[AnonymeMeow]

The pidfd API now supports pidfds for tasks that are not thread group leaders,
but fanotify has not caught up yet. This patch set lifts that restriction and
allows fanotify to report pidfds referring the event-generating thread.

Additionally, this patch set drops the pid_has_task() check before the
pidfd_prepare() call, allowing fanotify to hand out pidfds for reaped tasks,
as suggested by Christian.

Link: https://lore.kernel.org/lkml/20260528-schmuckvoll-heilen-garen-be77b4208671@brauner/

changes since v2:
 - Split the two independent changes into separate patches.

v2: https://lore.kernel.org/lkml/20260529020035.17477-1-anonymemeow@gmail.com/

AnonymeMeow (2):
  fanotify: report thread pidfds for FAN_REPORT_TID
  fanotify: allow reporting pidfds for reaped tasks

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

-- 
2.54.0

[PATCH v3 1/2] fanotify: report thread pidfds for FAN_REPORT_TID

[AnonymeMeow]

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.

Signed-off-by: AnonymeMeow <anonymemeow@gmail.com>
---
 fs/notify/fanotify/fanotify_user.c | 27 ++++++++-------------------
 1 file changed, 8 insertions(+), 19 deletions(-)

diff --git a/fs/notify/fanotify/fanotify_user.c b/fs/notify/fanotify/fanotify_user.c
index ae904451dfc0..ebdd48942029 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,21 @@ 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 tid_mode = FAN_GROUP_FLAG(group, FAN_REPORT_TID);
+		enum pid_type pidtype = tid_mode ? PIDTYPE_PID : PIDTYPE_TGID;
+		unsigned int pidfd_flags = tid_mode ? PIDFD_THREAD : 0;
 
 		/*
-		 * The PIDTYPE_TGID check for an event->pid is performed
+		 * The pid_has_task() 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
+		 * listener reads events after the event generating task 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 (metadata.pid && pid_has_task(event->pid, pidtype))
+			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 +1625,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

Re: [PATCH v3 1/2] fanotify: report thread pidfds for FAN_REPORT_TID

[Amir Goldstein]

On Sat, May 30, 2026 at 3:37 AM AnonymeMeow <anonymemeow@gmail.com> wrote:
>
> 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.
>
> Signed-off-by: AnonymeMeow <anonymemeow@gmail.com>

Reviewed-by: Amir Goldstein <amir73il@gmail.com>

Thanks,
Amir.

> ---
>  fs/notify/fanotify/fanotify_user.c | 27 ++++++++-------------------
>  1 file changed, 8 insertions(+), 19 deletions(-)
>
> diff --git a/fs/notify/fanotify/fanotify_user.c b/fs/notify/fanotify/fanotify_user.c
> index ae904451dfc0..ebdd48942029 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,21 @@ 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 tid_mode = FAN_GROUP_FLAG(group, FAN_REPORT_TID);
> +               enum pid_type pidtype = tid_mode ? PIDTYPE_PID : PIDTYPE_TGID;
> +               unsigned int pidfd_flags = tid_mode ? PIDFD_THREAD : 0;
>
>                 /*
> -                * The PIDTYPE_TGID check for an event->pid is performed
> +                * The pid_has_task() 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
> +                * listener reads events after the event generating task 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 (metadata.pid && pid_has_task(event->pid, pidtype))
> +                       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 +1625,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
>

[PATCH v3 2/2] fanotify: allow reporting pidfds for reaped tasks

[AnonymeMeow]

Fanotify used to refuse to report pidfds for reaped tasks by applying a
pid_has_task() check before calling pidfd_prepare(). This prevented
userspace from obtaining information about the task.

Fanotify events already hold a reference to the task's pid struct, so
the check can be safely dropped and pidfds can be reported for reaped
tasks as well.

Signed-off-by: AnonymeMeow <anonymemeow@gmail.com>
---
 fs/notify/fanotify/fanotify_user.c | 18 +++++-------------
 1 file changed, 5 insertions(+), 13 deletions(-)

diff --git a/fs/notify/fanotify/fanotify_user.c b/fs/notify/fanotify/fanotify_user.c
index ebdd48942029..b604e3da58ad 100644
--- a/fs/notify/fanotify/fanotify_user.c
+++ b/fs/notify/fanotify/fanotify_user.c
@@ -904,20 +904,12 @@ static ssize_t copy_event_to_user(struct fsnotify_group *group,
 		metadata.fd = fd >= 0 ? fd : FAN_NOFD;
 
 	if (pidfd_mode) {
-		unsigned int tid_mode = FAN_GROUP_FLAG(group, FAN_REPORT_TID);
-		enum pid_type pidtype = tid_mode ? PIDTYPE_PID : PIDTYPE_TGID;
-		unsigned int pidfd_flags = tid_mode ? PIDFD_THREAD : 0;
+		unsigned int pidfd_flags = PIDFD_STALE;
 
-		/*
-		 * The pid_has_task() 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 task 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))
+		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)
-- 
2.54.0

Re: [PATCH v3 2/2] fanotify: allow reporting pidfds for reaped tasks

[Amir Goldstein]

On Sat, May 30, 2026 at 3:37 AM AnonymeMeow <anonymemeow@gmail.com> wrote:
>
> Fanotify used to refuse to report pidfds for reaped tasks by applying a
> pid_has_task() check before calling pidfd_prepare(). This prevented
> userspace from obtaining information about the task.
>
> Fanotify events already hold a reference to the task's pid struct, so
> the check can be safely dropped and pidfds can be reported for reaped
> tasks as well.
>

I'd add:

Suggested-by: Christian Brauner <brauner@kernel.org>
Link: https://lore.kernel.org/linux-fsdevel/20260529-erdig-eckig-querulant-439a4ba4317d@brauner/

So when people come shouting we know who to blame ;)

> Signed-off-by: AnonymeMeow <anonymemeow@gmail.com>

Reviewed-by: Amir Goldstein <amir73il@gmail.com>

No need to post v4 just for adding those
Just add them if you happen to send v4 due some other review comments
and anyway we need to wait for Jan to wait in on this change

Thanks,
Amir.

> ---
>  fs/notify/fanotify/fanotify_user.c | 18 +++++-------------
>  1 file changed, 5 insertions(+), 13 deletions(-)
>
> diff --git a/fs/notify/fanotify/fanotify_user.c b/fs/notify/fanotify/fanotify_user.c
> index ebdd48942029..b604e3da58ad 100644
> --- a/fs/notify/fanotify/fanotify_user.c
> +++ b/fs/notify/fanotify/fanotify_user.c
> @@ -904,20 +904,12 @@ static ssize_t copy_event_to_user(struct fsnotify_group *group,
>                 metadata.fd = fd >= 0 ? fd : FAN_NOFD;
>
>         if (pidfd_mode) {
> -               unsigned int tid_mode = FAN_GROUP_FLAG(group, FAN_REPORT_TID);
> -               enum pid_type pidtype = tid_mode ? PIDTYPE_PID : PIDTYPE_TGID;
> -               unsigned int pidfd_flags = tid_mode ? PIDFD_THREAD : 0;
> +               unsigned int pidfd_flags = PIDFD_STALE;
>
> -               /*
> -                * The pid_has_task() 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 task 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))
> +               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)
> --
> 2.54.0
>

[RFC][PATCH] fanotify: register event pid for pidfd reporting

[AnonymeMeow]

pidfd_prepare() may still fail if userspace reads the event after the
task has been reaped and the pid has not been registered with pidfs.
Register the event pid with pidfs when creating the fanotify event if
pidfd reporting was requested, so pidfd_prepare() can later create a
pidfd for the reaped task.

Signed-off-by: AnonymeMeow <anonymemeow@gmail.com>
---

Hi, Christian,

I tested this patch set and found that fanotify still usually can not
report pidfds for reaped tasks, because the event pid may not have
been registered before it exits, and registering it after the task
has been reaped is not allowed, so fanotify still fails to report a
pidfd for the event.

This patch registers the event pid when the fanotify event is created.
With this change, the current LTP fanotify21 test fails as expected.

But I do not know whether it is worth doing so to improve fanotify's
ability to report pidfds for reaped tasks. And, what should fanotify
do if pidfs_register_pid() fails? Should the error be reported to
userspace through the pidfd info record, using the raw error when
FAN_REPORT_FD_ERROR is set and FAN_EPIDFD otherwise? But the event
struct in fanotify does not have spare space to store this error code.
Or should it just ignore the failure here and let pidfd_prepare()
fail later in copy_event_to_user()? I would appreciate your feedback.

With Best Regards,
AnonymeMeow

Link: https://lore.kernel.org/lkml/20260528-schmuckvoll-heilen-garen-be77b4208671@brauner/

---
 fs/notify/fanotify/fanotify.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c
index 38290b9c07f7..24b2af397126 100644
--- a/fs/notify/fanotify/fanotify.c
+++ b/fs/notify/fanotify/fanotify.c
@@ -14,6 +14,7 @@
 #include <linux/sched/mm.h>
 #include <linux/statfs.h>
 #include <linux/stringhash.h>
+#include <linux/pidfs.h>
 
 #include "fanotify.h"
 
@@ -868,6 +869,15 @@ static struct fanotify_event *fanotify_alloc_event(
 	else
 		pid = get_pid(task_tgid(current));
 
+	if (FAN_GROUP_FLAG(group, FAN_REPORT_PIDFD)) {
+		int err = pidfs_register_pid(pid);
+		if (err) {
+			/*
+			 * What to do here? Pass this err to userspace via pidfd?
+			 */
+		}
+	}
+
 	/* Mix event info, FAN_ONDIR flag and pid into event merge key */
 	hash ^= hash_long((unsigned long)pid | ondir, FANOTIFY_EVENT_HASH_BITS);
 	fanotify_init_event(event, hash, mask);
-- 
2.54.0

Re: [RFC][PATCH] fanotify: register event pid for pidfd reporting

[Jan Kara]

On Sat 30-05-26 18:51:17, AnonymeMeow wrote:
> pidfd_prepare() may still fail if userspace reads the event after the
> task has been reaped and the pid has not been registered with pidfs.
> Register the event pid with pidfs when creating the fanotify event if
> pidfd reporting was requested, so pidfd_prepare() can later create a
> pidfd for the reaped task.
> 
> Signed-off-by: AnonymeMeow <anonymemeow@gmail.com>

So the two patches in this series so far look good to me. This patch looks
OK to me as well and since the overhead of allocation etc. is only once per
registered task, I think it's fine but let's wait a bit whether Christian
agrees this is what needs to be done.

								Honza

> ---
> 
> Hi, Christian,
> 
> I tested this patch set and found that fanotify still usually can not
> report pidfds for reaped tasks, because the event pid may not have
> been registered before it exits, and registering it after the task
> has been reaped is not allowed, so fanotify still fails to report a
> pidfd for the event.
> 
> This patch registers the event pid when the fanotify event is created.
> With this change, the current LTP fanotify21 test fails as expected.
> 
> But I do not know whether it is worth doing so to improve fanotify's
> ability to report pidfds for reaped tasks. And, what should fanotify
> do if pidfs_register_pid() fails? Should the error be reported to
> userspace through the pidfd info record, using the raw error when
> FAN_REPORT_FD_ERROR is set and FAN_EPIDFD otherwise? But the event
> struct in fanotify does not have spare space to store this error code.
> Or should it just ignore the failure here and let pidfd_prepare()
> fail later in copy_event_to_user()? I would appreciate your feedback.
> 
> With Best Regards,
> AnonymeMeow
> 
> Link: https://lore.kernel.org/lkml/20260528-schmuckvoll-heilen-garen-be77b4208671@brauner/
> 
> ---
>  fs/notify/fanotify/fanotify.c | 10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c
> index 38290b9c07f7..24b2af397126 100644
> --- a/fs/notify/fanotify/fanotify.c
> +++ b/fs/notify/fanotify/fanotify.c
> @@ -14,6 +14,7 @@
>  #include <linux/sched/mm.h>
>  #include <linux/statfs.h>
>  #include <linux/stringhash.h>
> +#include <linux/pidfs.h>
>  
>  #include "fanotify.h"
>  
> @@ -868,6 +869,15 @@ static struct fanotify_event *fanotify_alloc_event(
>  	else
>  		pid = get_pid(task_tgid(current));
>  
> +	if (FAN_GROUP_FLAG(group, FAN_REPORT_PIDFD)) {
> +		int err = pidfs_register_pid(pid);
> +		if (err) {
> +			/*
> +			 * What to do here? Pass this err to userspace via pidfd?
> +			 */
> +		}
> +	}
> +
>  	/* Mix event info, FAN_ONDIR flag and pid into event merge key */
>  	hash ^= hash_long((unsigned long)pid | ondir, FANOTIFY_EVENT_HASH_BITS);
>  	fanotify_init_event(event, hash, mask);
> -- 
> 2.54.0
> 
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: [RFC][PATCH] fanotify: register event pid for pidfd reporting

[Christian Brauner]

On Mon, Jun 01, 2026 at 05:24:36PM +0200, Jan Kara wrote:
> On Sat 30-05-26 18:51:17, AnonymeMeow wrote:
> > pidfd_prepare() may still fail if userspace reads the event after the
> > task has been reaped and the pid has not been registered with pidfs.
> > Register the event pid with pidfs when creating the fanotify event if
> > pidfd reporting was requested, so pidfd_prepare() can later create a
> > pidfd for the reaped task.
> > 
> > Signed-off-by: AnonymeMeow <anonymemeow@gmail.com>
> 
> So the two patches in this series so far look good to me. This patch looks
> OK to me as well and since the overhead of allocation etc. is only once per

It's a kmem cache so should not matter at all...

> registered task, I think it's fine but let's wait a bit whether Christian
> agrees this is what needs to be done.

pidfs_register_pid() can only fail with ENOMEM or if the task is already
dead. The latter cannot happen because even for a non-empty thread group
where the thread-group leader already exited but subthreads are still
alive the thread-group leader cannot be reaped. So the only error here
is ENOMEM which means we should defo fail this, imho.

And yes, I think this is worth doing. Because you get a persistent
handle on the task that generated that event + all the exit information
even if that thask has been reaped in the meantime. I'm pretty sure if
you're using fanotify that's a rather huge win for apps that need it.

Re: [RFC][PATCH] fanotify: register event pid for pidfd reporting

[Jan Kara]

[-- Attachment #1: Type: text/plain, Size: 1763 bytes --]

On Tue 02-06-26 15:50:19, Christian Brauner wrote:
> On Mon, Jun 01, 2026 at 05:24:36PM +0200, Jan Kara wrote:
> > On Sat 30-05-26 18:51:17, AnonymeMeow wrote:
> > > pidfd_prepare() may still fail if userspace reads the event after the
> > > task has been reaped and the pid has not been registered with pidfs.
> > > Register the event pid with pidfs when creating the fanotify event if
> > > pidfd reporting was requested, so pidfd_prepare() can later create a
> > > pidfd for the reaped task.
> > > 
> > > Signed-off-by: AnonymeMeow <anonymemeow@gmail.com>
> > 
> > So the two patches in this series so far look good to me. This patch looks
> > OK to me as well and since the overhead of allocation etc. is only once per
> 
> It's a kmem cache so should not matter at all...
> 
> > registered task, I think it's fine but let's wait a bit whether Christian
> > agrees this is what needs to be done.
> 
> pidfs_register_pid() can only fail with ENOMEM or if the task is already
> dead. The latter cannot happen because even for a non-empty thread group
> where the thread-group leader already exited but subthreads are still
> alive the thread-group leader cannot be reaped. So the only error here
> is ENOMEM which means we should defo fail this, imho.
> 
> And yes, I think this is worth doing. Because you get a persistent
> handle on the task that generated that event + all the exit information
> even if that thask has been reaped in the meantime. I'm pretty sure if
> you're using fanotify that's a rather huge win for apps that need it.

OK, thanks for opinion. So I've somewhat massaged the error handling in the
patch AnonymeMeow. Attached is what I currently have in my tree (testing
pending).

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

[-- Attachment #2: 0001-fanotify-register-event-pid-for-pidfd-reporting.patch --]
[-- Type: text/x-patch, Size: 2612 bytes --]

From f1d94103161de2b233193faeeeb933a2f3c5584a Mon Sep 17 00:00:00 2001
From: AnonymeMeow <anonymemeow@gmail.com>
Date: Sat, 30 May 2026 18:51:17 +0800
Subject: [PATCH] fanotify: register event pid for pidfd reporting

pidfd_prepare() may still fail if userspace reads the event after the
task has been reaped and the pid has not been registered with pidfs.
Register the event pid with pidfs when creating the fanotify event if
pidfd reporting was requested, so pidfd_prepare() can later create a
pidfd for the reaped task.

[JK: Reworked error handling ]

Signed-off-by: AnonymeMeow <anonymemeow@gmail.com>
Link: https://patch.msgid.link/20260530105117.45792-1-anonymemeow@gmail.com
Signed-off-by: Jan Kara <jack@suse.cz>
---
 fs/notify/fanotify/fanotify.c | 22 +++++++++++++++-------
 1 file changed, 15 insertions(+), 7 deletions(-)

diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c
index 8ed77901db57..de013dd132d7 100644
--- a/fs/notify/fanotify/fanotify.c
+++ b/fs/notify/fanotify/fanotify.c
@@ -14,6 +14,7 @@
 #include <linux/sched/mm.h>
 #include <linux/statfs.h>
 #include <linux/stringhash.h>
+#include <linux/pidfs.h>
 
 #include "fanotify.h"
 
@@ -760,7 +761,7 @@ static struct fanotify_event *fanotify_alloc_event(
 	bool name_event = false;
 	unsigned int hash = 0;
 	bool ondir = mask & FAN_ONDIR;
-	struct pid *pid;
+	struct pid *pid = NULL;
 
 	if ((fid_mode & FAN_REPORT_DIR_FID) && dirid) {
 		/*
@@ -839,6 +840,16 @@ static struct fanotify_event *fanotify_alloc_event(
 	/* Whoever is interested in the event, pays for the allocation. */
 	old_memcg = set_active_memcg(group->memcg);
 
+	if (FAN_GROUP_FLAG(group, FAN_REPORT_TID))
+		pid = get_pid(task_pid(current));
+	else
+		pid = get_pid(task_tgid(current));
+
+	/* Prepare task for creating pidfd for it even if it exits */
+	if (FAN_GROUP_FLAG(group, FAN_REPORT_PIDFD))
+		if (pidfs_register_pid(pid))
+			goto out;
+
 	if (fanotify_is_perm_event(mask)) {
 		event = fanotify_alloc_perm_event(data, data_type, gfp);
 	} else if (fanotify_is_error_event(mask)) {
@@ -860,17 +871,14 @@ static struct fanotify_event *fanotify_alloc_event(
 	if (!event)
 		goto out;
 
-	if (FAN_GROUP_FLAG(group, FAN_REPORT_TID))
-		pid = get_pid(task_pid(current));
-	else
-		pid = get_pid(task_tgid(current));
-
 	/* Mix event info, FAN_ONDIR flag and pid into event merge key */
 	hash ^= hash_long((unsigned long)pid | ondir, FANOTIFY_EVENT_HASH_BITS);
 	fanotify_init_event(event, hash, mask);
 	event->pid = pid;
-
+	pid = NULL;
 out:
+	if (pid)
+		put_pid(pid);
 	set_active_memcg(old_memcg);
 	return event;
 }
-- 
2.51.0

Re: [RFC][PATCH] fanotify: register event pid for pidfd reporting

[Jan Kara]

On Mon 08-06-26 11:27:01, Jan Kara wrote:
> On Tue 02-06-26 15:50:19, Christian Brauner wrote:
> > On Mon, Jun 01, 2026 at 05:24:36PM +0200, Jan Kara wrote:
> > > On Sat 30-05-26 18:51:17, AnonymeMeow wrote:
> > > > pidfd_prepare() may still fail if userspace reads the event after the
> > > > task has been reaped and the pid has not been registered with pidfs.
> > > > Register the event pid with pidfs when creating the fanotify event if
> > > > pidfd reporting was requested, so pidfd_prepare() can later create a
> > > > pidfd for the reaped task.
> > > > 
> > > > Signed-off-by: AnonymeMeow <anonymemeow@gmail.com>
> > > 
> > > So the two patches in this series so far look good to me. This patch looks
> > > OK to me as well and since the overhead of allocation etc. is only once per
> > 
> > It's a kmem cache so should not matter at all...
> > 
> > > registered task, I think it's fine but let's wait a bit whether Christian
> > > agrees this is what needs to be done.
> > 
> > pidfs_register_pid() can only fail with ENOMEM or if the task is already
> > dead. The latter cannot happen because even for a non-empty thread group
> > where the thread-group leader already exited but subthreads are still
> > alive the thread-group leader cannot be reaped. So the only error here
> > is ENOMEM which means we should defo fail this, imho.
> > 
> > And yes, I think this is worth doing. Because you get a persistent
> > handle on the task that generated that event + all the exit information
> > even if that thask has been reaped in the meantime. I'm pretty sure if
> > you're using fanotify that's a rather huge win for apps that need it.
> 
> OK, thanks for opinion. So I've somewhat massaged the error handling in the
> patch AnonymeMeow. Attached is what I currently have in my tree (testing
> pending).

OK, reverted that for now since I've found further versions of the series
in my huge inbox after a few days of vacation now :).

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: [RFC][PATCH] fanotify: register event pid for pidfd reporting

[Christian Brauner]

On Mon, Jun 08, 2026 at 02:30:45PM +0200, Jan Kara wrote:
> On Mon 08-06-26 11:27:01, Jan Kara wrote:
> > On Tue 02-06-26 15:50:19, Christian Brauner wrote:
> > > On Mon, Jun 01, 2026 at 05:24:36PM +0200, Jan Kara wrote:
> > > > On Sat 30-05-26 18:51:17, AnonymeMeow wrote:
> > > > > pidfd_prepare() may still fail if userspace reads the event after the
> > > > > task has been reaped and the pid has not been registered with pidfs.
> > > > > Register the event pid with pidfs when creating the fanotify event if
> > > > > pidfd reporting was requested, so pidfd_prepare() can later create a
> > > > > pidfd for the reaped task.
> > > > > 
> > > > > Signed-off-by: AnonymeMeow <anonymemeow@gmail.com>
> > > > 
> > > > So the two patches in this series so far look good to me. This patch looks
> > > > OK to me as well and since the overhead of allocation etc. is only once per
> > > 
> > > It's a kmem cache so should not matter at all...
> > > 
> > > > registered task, I think it's fine but let's wait a bit whether Christian
> > > > agrees this is what needs to be done.
> > > 
> > > pidfs_register_pid() can only fail with ENOMEM or if the task is already
> > > dead. The latter cannot happen because even for a non-empty thread group
> > > where the thread-group leader already exited but subthreads are still
> > > alive the thread-group leader cannot be reaped. So the only error here
> > > is ENOMEM which means we should defo fail this, imho.
> > > 
> > > And yes, I think this is worth doing. Because you get a persistent
> > > handle on the task that generated that event + all the exit information
> > > even if that thask has been reaped in the meantime. I'm pretty sure if
> > > you're using fanotify that's a rather huge win for apps that need it.
> > 
> > OK, thanks for opinion. So I've somewhat massaged the error handling in the
> > patch AnonymeMeow. Attached is what I currently have in my tree (testing
> > pending).
> 
> OK, reverted that for now since I've found further versions of the series
> in my huge inbox after a few days of vacation now :).

Fsck flooded inboxes, vacation is important. :)

Re: [PATCH v3 0/2] fanotify: lift pidfd reporting restrictions

[Jan Kara]

On Sat 30-05-26 09:37:30, AnonymeMeow wrote:
> The pidfd API now supports pidfds for tasks that are not thread group leaders,
> but fanotify has not caught up yet. This patch set lifts that restriction and
> allows fanotify to report pidfds referring the event-generating thread.
> 
> Additionally, this patch set drops the pid_has_task() check before the
> pidfd_prepare() call, allowing fanotify to hand out pidfds for reaped tasks,
> as suggested by Christian.
> 
> Link: https://lore.kernel.org/lkml/20260528-schmuckvoll-heilen-garen-be77b4208671@brauner/
> 
> changes since v2:
>  - Split the two independent changes into separate patches.
> 
> v2: https://lore.kernel.org/lkml/20260529020035.17477-1-anonymemeow@gmail.com/

OK, I have taken these patches into my tree now. Can you please send fixes
for LTP tests fanotify20 and fanotify21?

								Honza

> 
> AnonymeMeow (2):
>   fanotify: report thread pidfds for FAN_REPORT_TID
>   fanotify: allow reporting pidfds for reaped tasks
> 
>  fs/notify/fanotify/fanotify_user.c | 33 +++++++-----------------------
>  1 file changed, 7 insertions(+), 26 deletions(-)
> 
> -- 
> 2.54.0
> 
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR