From: "Luming Yu" <luming.yu@gmail.com>
To: Roland McGrath <roland@redhat.com>
Cc: Petr Tesarik <ptesarik@suse.cz>,
LKML <linux-kernel@vger.kernel.org>,
linux-ia64@vger.kernel.org
Subject: Re: [RFC PATCH] set TASK_TRACED before arch_ptrace code to fix a race
Date: Tue, 16 Sep 2008 08:50:24 +0000 [thread overview]
Message-ID: <3877989d0809160150y385edd59i231aca8b1073ce14@mail.gmail.com> (raw)
In-Reply-To: <20080910055504.9A2A41541FE@magilla.localdomain>
On Wed, Sep 10, 2008 at 1:55 PM, Roland McGrath <roland@redhat.com> wrote:
> This subject line is quite far from what you're now addressing, btw.
>
> I certainly wouldn't recommend that patch. The interference between ptrace
> uses of SIGTRAP and a program that blocks SIGTRAP is just a fact of life
> with ptrace. If you wanted to change the exec SIGTRAP to be more
> consistent with other signals induced by debuggers (such as breakpoints and
> single-step), you could just change send_sig to force_sig. That unblocks
> SIGTRAP and resets its handler when it's blocked. Conversely, a tracer
> program could use PTRACE_O_TRACEEXEC if it cared to deal with tracing a
> process that blocks SIGTRAP. (That uses ptrace_notify rather than any
> actual signal that can be blocked.)
>
> But, none of this goes to your actual problem at all AFAICT. You've said
> your actual problem with strace only arises on ia64. The behavior of
> ptrace'd exec, and the effect of a program blocking SIGTRAP, is exactly the
> same across all machines. Changing it does not explain your situation.
> I'm in favor of understanding what is actually going on before changing
> things.
>
> If the SIGTRAP from exec is actually seen by strace on a different machine
> like it's not on ia64, that suggests that something different happened
> between the two. In the case that doesn't exhibit the problem, either
> SIGTRAP got unblocked by something before the exec, or userland (strace)
> behaves differently so that it doesn't care about not seeing that SIGTRAP.
The reason is not as complicated as I thought. It is because x86
strace don't test TCB_WAITEXECVE. please take a look at defs.h
(strace-4.5.16), the flag is defined as follows:
#ifdef LINUX
# if defined(ALPHA) || defined(SPARC) || defined(SPARC64) ||
defined(POWERPC) || defined(IA64) || defined(HPPA) || defined(SH) ||
defined(SH64) || defined(S390) || defined(S390X) || defined(ARM)
# define TCB_WAITEXECVE 02000 /* ignore SIGTRAP after exceve */
# endif
I'm not an strace expert, so I have no idea what the TCB_WAITEXECVE means.
And why x86 strace can handle SIGTRAP after execve but ALL other Arch can not..
Could anybody shield some lights on the flag?
next prev parent reply other threads:[~2008-09-16 8:50 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-22 2:47 [RFC PATCH] set TASK_TRACED before arch_ptrace code to fix a race Luming Yu
2008-05-22 8:47 ` [RFC PATCH] set TASK_TRACED before arch_ptrace code to fix a Petr Tesarik
2008-05-22 9:16 ` [RFC PATCH] set TASK_TRACED before arch_ptrace code to fix a race Luming Yu
2008-05-22 11:18 ` Roland McGrath
2008-05-22 12:12 ` [RFC PATCH] set TASK_TRACED before arch_ptrace code to fix a Petr Tesarik
2008-05-22 20:39 ` Roland McGrath
2008-05-23 12:33 ` [RFC PATCH] set TASK_TRACED before arch_ptrace code to fix a race Luming Yu
2008-05-22 13:24 ` Luming Yu
2008-05-22 20:34 ` Roland McGrath
2008-05-23 3:42 ` Luming Yu
2008-05-23 4:19 ` Roland McGrath
2008-05-23 5:24 ` Luming Yu
2008-05-26 0:15 ` Roland McGrath
2008-05-26 1:30 ` Luming Yu
2008-05-27 3:31 ` Luming Yu
2008-05-27 4:04 ` Roland McGrath
2008-05-27 5:49 ` Luming Yu
2008-05-27 6:12 ` Roland McGrath
2008-05-27 6:25 ` [RFC PATCH] set TASK_TRACED before arch_ptrace code to fix a Petr Tesarik
2008-06-03 6:04 ` [RFC PATCH] set TASK_TRACED before arch_ptrace code to fix a race Luming Yu
2008-06-03 9:01 ` [RFC PATCH] set TASK_TRACED before arch_ptrace code to fix a Petr Tesarik
2008-06-03 14:32 ` Petr Tesarik
2008-06-03 21:01 ` Roland McGrath
2008-06-03 21:31 ` [RFC PATCH] set TASK_TRACED before arch_ptrace code to fix a race Luck, Tony
2008-06-03 22:13 ` Roland McGrath
2008-06-10 8:23 ` Luming Yu
2008-06-04 2:16 ` Luming Yu
2008-06-04 9:16 ` [RFC PATCH] set TASK_TRACED before arch_ptrace code to fix a Petr Tesarik
2008-06-05 1:49 ` [RFC PATCH] set TASK_TRACED before arch_ptrace code to fix a race Luming Yu
2008-06-05 11:16 ` [RFC PATCH] set TASK_TRACED before arch_ptrace code to fix a Petr Tesarik
2008-06-06 0:07 ` Roland McGrath
2008-09-09 3:06 ` [RFC PATCH] set TASK_TRACED before arch_ptrace code to fix a race Luming Yu
2008-09-10 5:55 ` Roland McGrath
2008-09-16 8:50 ` Luming Yu [this message]
2008-09-17 17:01 ` Roland McGrath
2008-09-18 5:44 ` Luming Yu
2008-05-27 6:34 ` Luming Yu
2008-05-27 8:48 ` Luming Yu
2008-05-28 9:14 ` Luming Yu
2008-06-03 6:02 ` Luming Yu
2008-05-30 8:05 ` 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=3877989d0809160150y385edd59i231aca8b1073ce14@mail.gmail.com \
--to=luming.yu@gmail.com \
--cc=linux-ia64@vger.kernel.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