On Thu, Mar 20, 2025 at 03:02:00PM +0100, Oleg Nesterov wrote: > On 03/20, Christian Brauner wrote: > > > > What you seem to be saying is that you want all references to > > PIDFD_THREAD to be dropped in the comments because the behavior is now > > identical. > > yes, to me the references to PIDFD_THREAD look as if PIDFD_THREAD > has some subtle differences in behavior. > > With or without PIDFD_THREAD, do_notify_pidfd() is called and pidfd_poll() > returns EPOLLIN when this thread (leader or not) is ready for wait() from > the parent or debugger. > > But! > > > So I'm wiping the comments but I very much disagree that they are > > misleading/useless. > > No, if you don't agree than do not remove the comments ;) No, it's fine. We always find some compromise and I've reworded the comments substantially to not rely on PIDFD_THREAD at all. I always appreciate the feedback, don't get me wrong! > And... can you explain the motivation for this patch? Yes, sure. > > I mean... Again, the current PIDFD_THREAD/group-leader behavior is > not well defined, this is clear. > > But if user-space does sys_pidfd_open(group_leader_pid) and needs the > "correct" EPOLLIN when the whole process exits, then it should not use > PIDFD_THREAD ? > > Just in case, I am not arguing, I am just trying to understand. One driver is consistency. It's really weird to sometimes get exit notifications and sometimes don't. It's easier to understand that we delay notification until the thread-group is empty for a thread-based pidfd for a thread-group leader rather than explaining de_thread() timing issues for subthread exec. But also remembering our earlier discussion on PIDFD_INFO_EXIT: If the thread-group leader exits prematurely and userspace gets an exit notification they end up with a Zombie they cannot (yet) reap. I don't think we should carry that behavior over into the pidfd api. I'd rather have it be so that if you get an exit notification it means that you can may now reap the thing (I'm probably unaware of some ptrace induced behavior that render this statement wrong.).