From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756513AbcIVJxH (ORCPT ); Thu, 22 Sep 2016 05:53:07 -0400 Received: from mail-wm0-f65.google.com ([74.125.82.65]:34479 "EHLO mail-wm0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753303AbcIVJxG (ORCPT ); Thu, 22 Sep 2016 05:53:06 -0400 Date: Thu, 22 Sep 2016 11:53:03 +0200 From: Michal Hocko To: Mike Galbraith Cc: LKML , strace-devel@lists.sourceforge.net, Oleg Nesterov , Aleksa Sarai Subject: Re: strace lockup when tracing exec in go Message-ID: <20160922095303.GD11875@dhcp22.suse.cz> References: <20160921152946.GA24210@dhcp22.suse.cz> <1474517702.4851.21.camel@gmail.com> <20160922080126.GA11875@dhcp22.suse.cz> <20160922083602.GB11875@dhcp22.suse.cz> <1474537209.5022.8.camel@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1474537209.5022.8.camel@gmail.com> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu 22-09-16 11:40:09, Mike Galbraith wrote: > On Thu, 2016-09-22 at 10:36 +0200, Michal Hocko wrote: > > 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. > > > > */ > > This patch doesn't help, nor does the previous patch... but with both > applied, all is well. All you have to do now is figure out why :) Ohh, I should be more explicit, this needs the mm_access part as well. Sorry for not being clear enough. So the full change is --- diff --git a/kernel/fork.c b/kernel/fork.c index 5a57b9bab85c..d5b7c3aea187 100644 --- a/kernel/fork.c +++ b/kernel/fork.c @@ -837,7 +837,7 @@ struct mm_struct *mm_access(struct task_struct *task, unsigned int mode) struct mm_struct *mm; int err; - err = mutex_lock_killable(&task->signal->cred_guard_mutex); + err = mutex_lock_interruptible(&task->signal->cred_guard_mutex); if (err) return ERR_PTR(err); diff --git a/kernel/signal.c b/kernel/signal.c index 96e9bc40667f..5c8b84b76f0b 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