On So, 02.03.25 21:24, Oleg Nesterov (oleg@xxxxxxxxxx) wrote: > This will fix the problem with mt-exec, but this won't help to discriminate > the leader-exit and the-whole-group-exit cases... > > With this this (or something like this) change pidfd_info() can only report > the exit code of the already reaped thread/process, leader or not. > > I mean... If the leader L exits using sys_exit() and it has the live sub- > threads, release_task(L) / __unhash_process(L) will be only called when > the last sub-thread exits and it (or debugger) does "goto repeat;" in > release_task() to finally reap the leader. > > IOW. If someone does sys_pidfd_create(group-leader-pid, PIDFD_THREAD), > pidfd_info() won't report PIDFD_INFO_EXIT if the leader has exited using > sys_exit() before other threads. > > But perhaps this is fine? I think this is fine, but I'd really like a way how userspace can determine this state reliably. i.e. a zombie state where the exit status is not available yet is a bit strange by classic UNIX standards on some level, no? But I guess that might not be a pidfd specific issue. i.e. I figure classic waitid() with WNOHANG failing on a zombie process that is set up like that is a bit weird too, no? Or how does that work there? (pretty sure some userspace might not be expecting that...) Lennart -- Lennart Poettering, Berlin
