From: Michal H. <mh...@ke...> - 2016-09-22 08:36:11
|
On Thu 22-09-16 10:01:26, Michal Hocko wrote: > On Thu 22-09-16 06:15:02, Mike Galbraith wrote: > [...] > > master.today... > > Thanks for trying to reproduce this. My tiny laptop (2 cores, 2 threads > per core) cannot reproduce even in 10 minutes or so. I've tried to use > the same machine I was testing with 3.12 kernel (2 sockets, 8 cores per > soc. and 2 threas per core) and it hit almost instantly. I have tried > mutex_lock_killable -> interruptible and it didn't help as I've > expected. So the current kernel doesn't do any magic to prevent from the > issue as well. > > So I've stared into do_notify_parent some more and the following was > just very confusing > > if (!tsk->ptrace && sig == SIGCHLD && > (psig->action[SIGCHLD-1].sa.sa_handler == SIG_IGN || > (psig->action[SIGCHLD-1].sa.sa_flags & SA_NOCLDWAIT))) { > /* > * 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. > * Rather than having the parent do it as a magic kind of > * signal handler, we just set this to tell do_exit that we > * can be cleaned up without becoming a zombie. Note that > * we still call __wake_up_parent in this case, because a > * blocked sys_wait4 might now return -ECHILD. > * > * Whether we send SIGCHLD or not for SA_NOCLDWAIT > * is implementation-defined: we do (if you don't want > * it, just use SIG_IGN instead). > */ > autoreap = true; > if (psig->action[SIGCHLD-1].sa.sa_handler == SIG_IGN) > sig = 0; > } > > it tries to prevent from what I am seeing in a way. If the SIGCHLD is > ignored then it just does autoreap and everything is fine. But this > doesn't seem to be the case here. In fact we are not sending the signal > because sig_task_ignored is true resp. sig_handler_ignored which can > fail even for handler == SIG_DFL && sig_kernel_ignore() and SIGCHLD > seems to be in SIG_KERNEL_IGNORE_MASK. So I've tried Dohh, I've missed !tsk->ptrace check there. So we are not even going that via that path. So the sig_handler_ignored cannot possible help. I was just too lucky and didn't hit the lockup with the patch. So what else might be wrong here? sig_ignored seems to be quite confusing /* * Tracers may want to know about even ignored signals. */ return !t->ptrace; t is the tracer here but it shouldn't have t->ptrace because the child is not stopped. So do we need something like the following? Not tested yet diff --git a/kernel/signal.c b/kernel/signal.c index 1840c7f4e3c2..bd236ce4a29c 100644 --- a/kernel/signal.c +++ b/kernel/signal.c @@ -91,6 +91,10 @@ static int sig_ignored(struct task_struct *t, int sig, bool force) if (!sig_task_ignored(t, sig, force)) return 0; + /* Do not ignore signals sent from child to the parent */ + if (current->ptrace && current->parent == t) + return 0; + /* * Tracers may want to know about even ignored signals. */ -- Michal Hocko SUSE Labs |