From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1034406AbcIWNlE (ORCPT ); Fri, 23 Sep 2016 09:41:04 -0400 Received: from mail-wm0-f48.google.com ([74.125.82.48]:36494 "EHLO mail-wm0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1030326AbcIWNlC (ORCPT ); Fri, 23 Sep 2016 09:41:02 -0400 Date: Fri, 23 Sep 2016 15:40:59 +0200 From: Michal Hocko To: Oleg Nesterov Cc: LKML , strace-devel@lists.sourceforge.net, Mike Galbraith , Aleksa Sarai Subject: Re: strace lockup when tracing exec in go Message-ID: <20160923134058.GP4478@dhcp22.suse.cz> References: <20160922080126.GA11875@dhcp22.suse.cz> <20160922083602.GB11875@dhcp22.suse.cz> <1474537209.5022.8.camel@gmail.com> <20160922095303.GD11875@dhcp22.suse.cz> <1474538945.5022.20.camel@gmail.com> <20160922110925.GE11875@dhcp22.suse.cz> <20160922135301.GF11875@dhcp22.suse.cz> <20160923102141.GA16189@redhat.com> <20160923111808.GJ4478@dhcp22.suse.cz> <20160923132101.GA27178@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160923132101.GA27178@redhat.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 Fri 23-09-16 15:21:02, Oleg Nesterov wrote: > On 09/23, Michal Hocko wrote: > > > > On Fri 23-09-16 12:21:41, Oleg Nesterov wrote: > > > On 09/22, Michal Hocko wrote: > > > > > > > > --- 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; > > > > > > This doesn't look right in general, and this can't really help. > > > > > > This assumes that the tracer will call do_wait() after mm_access() > > > fails, but this is not necessarily true. > > > > > > Note also ptrace_attach(), -ERESTARTNOINTR means that the tracer won't > > > even return to user-space if SIGCHLD is ignored, the tracer will silently > > > restart the syscall. > > > > Well, it apparently does help the strace case. > > Only because strace doesn't even try to handle -EINTR; it assumes this is not > possible, gives up, and calls wait() after that. So this change actually > breaks strace. Hmm, OK. In this case process_vm_readv wouldn't give a usuful data which still sounds better to me than a hang. > And once again, this can't really help. SIGCHLD can come before strace calls > process_vm_readv(), and in this case it will enter the syscall without > signal_pending() == T. IOW, this hack can only help if the tracer already > sleeps in process_vm_readv(). True. > Plus, again, "strace -f" can equally hang if mt-exec races with PTRACE_ATTACH. > > > So I am not arguing this > > is the best fix but can it be harmful? > > This change is simply wrong no matter what. I've just tried to extend the existing /* * Tracers may want to know about even ignored signals. */ return !t->ptrace; but I probably just do not understand what that actually means. I thought that the tracer is _really_ interested in hearing about the signal. > We could change do_notify_parent() > to call signal_wake_up() if tsk->ptrace, but see above, this won't help. So does this mean WONTFIX? Can we at least document this behavior? It surely is unexpected. -- Michal Hocko SUSE Labs