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@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).

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