From: Michal Hocko <mhocko@kernel.org>
To: Oleg Nesterov <oleg@redhat.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
strace-devel@lists.sourceforge.net,
Mike Galbraith <umgwanakikbuti@gmail.com>,
Aleksa Sarai <asarai@suse.com>
Subject: Re: strace lockup when tracing exec in go
Date: Fri, 23 Sep 2016 15:40:59 +0200 [thread overview]
Message-ID: <20160923134058.GP4478@dhcp22.suse.cz> (raw)
In-Reply-To: <20160923132101.GA27178@redhat.com>
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
next prev parent reply other threads:[~2016-09-23 13:41 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-21 15:29 strace lockup when tracing exec in go Michal Hocko
2016-09-22 4:15 ` Mike Galbraith
2016-09-22 8:01 ` Michal Hocko
2016-09-22 8:20 ` Aleksa Sarai
2016-09-22 8:36 ` Michal Hocko
2016-09-22 9:40 ` Mike Galbraith
2016-09-22 9:53 ` Michal Hocko
2016-09-22 10:09 ` Mike Galbraith
2016-09-22 11:09 ` Michal Hocko
2016-09-22 13:53 ` Michal Hocko
2016-09-23 1:17 ` Aleksa Sarai
2016-09-23 10:21 ` Oleg Nesterov
2016-09-23 11:18 ` Michal Hocko
2016-09-23 13:21 ` Oleg Nesterov
2016-09-23 13:40 ` Michal Hocko [this message]
2016-09-23 14:07 ` Oleg Nesterov
2016-09-23 14:19 ` Michal Hocko
2016-09-23 9:50 ` Oleg Nesterov
2016-09-23 11:23 ` Michal Hocko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160923134058.GP4478@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=asarai@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=strace-devel@lists.sourceforge.net \
--cc=umgwanakikbuti@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).