Messages in this thread |  | | | Date | Tue, 19 Apr 2011 19:20:36 +0200 | | From | Oleg Nesterov <> | | Subject | Re: [path][rfc] add PR_DETACH prctl command [3/3] |
| |
On 04/19, Stas Sergeev wrote: > > 19.04.2011 20:29, Oleg Nesterov wrote: >>> I'll try to check these patches from the correctness pov tomorrow, >>> but to be honest I hope someone will nack them before I start ;) >> OK, I briefly looked at 3/3. It looks certainly wrong. >> >> notif = do_signal_parent(...); >> if (notif != DEATH_REAP) { >> .... >> >> do_signal_parent() must not return DEATH_REAP (this means that >> leader->exit_signal becomes -1), but this can happen and this is bug. >> > Could you please clarify this a bit: according to the comments > in signal.c: > --- > * We are exiting and our parent doesn't care. POSIX.1 > * defines special semantics for setting SIGCHLD to SIG_IGN > * or setting the SA_NOCLDWAIT flag: we should be reaped > * automatically and not left for our parent's wait4 call. > --- > That's how I understand it: if DEATH_REAP is returned, the > parent ignores SIGCHILD, and in this case I am not allowing > it to read the detach code with wait(). What is the bug?
Indeed. But, once again, that is why do_notify_parent() expects the dead tsk! Please note that if it returns DEATH_REAP it sets ->exit_signal = -1. And this is _only_ allowed if the leader is already dead and we are going to reap it.
>> Also. I didn't actually read the patch yet, but iiuc: if a task T does >> PR_DETACH and then exits, init can't reap it until the old parent does >> wait. This can confuse the poor admin, he can see the zombies with >> ppid = 1 and there is no way to understand why. > Oh my. :)) I guess you are not going to suggest a solution to > that "problem", other than to rip the patch? :)
Cough... well, the mentioned solution looks very nice to me ;)
Oleg.
|  |