public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
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?

  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