From: Oleg Nesterov <oleg@tv-sign.ru>
To: Petr Tesarik <ptesarik@suse.cz>
Cc: linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Roland McGrath <roland@redhat.com>
Subject: Re: [PATCH] Discard notification signals when a tracer exits
Date: Tue, 25 Mar 2008 19:16:06 +0300 [thread overview]
Message-ID: <20080325161606.GA93@tv-sign.ru> (raw)
In-Reply-To: <1206455513.17227.4.camel@elijah.suse.cz>
This patch needs Roland's opinion. I can't really judge, but I
have some (perhaps wrong) doubts.
On 03/25, Petr Tesarik wrote:
>
> When a tracer exits without detaching from the traced process, the
> tracee may be at a tracer notification stop and will thus interpret
> the value in task->exit_code (SIGTRAP | 0x80) as the signal to be
> delivered.
>
> This patch fixes the problem by clearing exit_code when detaching
> the traced process from a dying tracer.
>
> Signed-off-by: Petr Tesarik <ptesarik@suse.cz>
>
> ---
> exit.c | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> --- a/kernel/exit.c
> +++ b/kernel/exit.c
> @@ -642,8 +642,10 @@ reparent_thread(struct task_struct *p, s
> /*
> * If it was at a trace stop, turn it into
> * a normal stop since it's no longer being
> - * traced.
> + * traced. Cancel the notification signal,
> + * or the tracee may get a SIGTRAP.
> */
> + p->exit_code = 0;
> ptrace_untrace(p);
> }
> }
> @@ -713,6 +715,10 @@ static void forget_original_parent(struc
> p->real_parent = reaper;
> reparent_thread(p, father, 0);
> } else {
> + /* cancel the notification signal at a trace stop */
> + if (p->state == TASK_TRACED)
> + p->exit_code = 0;
This reduce the likelihood that the tracee will be SIGTRAP'ed, but doesn't
solve the problem, no?
Suppose that the tracee does send_sigtrap(current) in do_syscall_trace()
and then ptracer exits. Or ptracer wakes up the TASK_TRACED tracee without
clearing its ->exit_code and then you kill(ptracer, SIGKILL).
If we really need this, _perhaps_ it is better to change do_syscall_trace(),
so that the tracee checks ->ptrace before sending the signal to itself.
But actually, I don't understand what is the problem. Ptracer has full control,
you should not kill it with SIGKILL, this may leave the child in some bad/
inconsistent change. If strace/whatever itself exits without taking care about
its tracees, then we should fix the tracer, not the kernel.
Yes, I think this can prevent the death of the tracee if you do kill(strace,9),
but why this is important? Why should you kill it with SIGKILL?
But again, let's see what Roland thinks.
Oleg.
next prev parent reply other threads:[~2008-03-25 16:11 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-25 14:31 Petr Tesarik
2008-03-25 14:37 ` Petr Tesarik
2008-03-25 16:16 ` Oleg Nesterov [this message]
2008-03-25 16:33 ` Oleg Nesterov
2008-03-26 9:13 ` Petr Tesarik
2008-03-26 8:48 ` Petr Tesarik
2008-03-26 18:17 ` Oleg Nesterov
2008-03-27 8:06 ` Petr Tesarik
2008-03-27 13:44 ` Oleg Nesterov
2008-03-25 22:38 ` Roland McGrath
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=20080325161606.GA93@tv-sign.ru \
--to=oleg@tv-sign.ru \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ptesarik@suse.cz \
--cc=roland@redhat.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
all inboxes | Powered by JetHome®