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

From: Jan Kara

Date: Mon Jun 08 2026 - 05:33:28 EST


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@xxxxxxxxx>
> >
> > 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@xxxxxxxx>
SUSE Labs, CR