Re: [PATCH v3 1/3] pidfd: allow pidfd_open() on non-thread-group leaders
From: Tycho Andersen <tycho@tycho.pizza>
Date: 2024-01-27 17:20:57
Also in:
lkml
On Sat, Jan 27, 2024 at 05:31:39PM +0100, Oleg Nesterov wrote:
On 01/27, Tycho Andersen wrote:quoted
It seems like (and the current pidfd_test enforces for some cases)Which pidfd_test ?
I was thinking of poll_pidfd() in pidfd_test.c, but,
quoted
we want exactly one notification for a task dying.This can't be right. EVERY user of poll_wait() or wait_event/etc must handle/tolerate the false wakeups.
you're right, it doesn't enforce exactly once.
quoted
I don't understand how we guarantee this now, with all of these calls.I don't understand why do we need or even want to guarantee this. The extra wakeup must be always fine correctness-wise. Sure, it would be nice to avoid the unnecessary wakeups, and perhaps we can change wake_up_all() to pass a key to, say, only wake_up the PIDFD_THREAD waiters from exit_notify(). But certainly this is outside the scope of PIDFD_THREAD change we discuss. The changes in do_notify_parent() (I have already sent the patch) and in exit_notify() (proposed in my previous email) just ensure that, with the minimal changes, we avoid 2 do_notify_pidfd's from the same exit_notify() path.
Sounds good.
quoted
quoted
exit_notify() is called after exit_files(). pidfd_getfd() returns ESRCH if the exiting thread completes release_task(), otherwise it returns EBADF because ->files == NULL. This too doesn't really depend on PIDFD_THREAD.Yup, understood. It just seems like an inconsistency we might want to fix.Not sure this worth "fixing"...
Yep, maybe not. Just wanted to point it out. Tycho