[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3877989d0805220624i259a9d1j708795c65c636ca0@mail.gmail.com>
Date: Thu, 22 May 2008 21:24:11 +0800
From: "Luming Yu" <luming.yu@...il.com>
To: "Roland McGrath" <roland@...hat.com>
Cc: "Petr Tesarik" <ptesarik@...e.cz>,
LKML <linux-kernel@...r.kernel.org>, linux-ia64@...r.kernel.org
Subject: Re: [RFC PATCH] set TASK_TRACED before arch_ptrace code to fix a race
On Thu, May 22, 2008 at 7:18 PM, Roland McGrath <roland@...hat.com> wrote:
> I really cannot figure out from anything you've said what the failure mode
> is or how you think it should be affected.
Sorry for confusion, Let me try to explain it more:
For ia64,the code path is like:
ptrace_notify (to let the debugger run)--> ptrace_stop
-->spin_unlock_irq->arch_ptrace_stop (ia64_ptrace_stop) ->[sync rbs
and set NOTIFY_RESUME.....]-->spin_lock_irq->set TASK_TRACED flag (to
let the debugger run)
For x86, the code path is like:
ptrace_notify (to let the debugger run) ->ptrace_stop->set TASK_TRACED
flag (to let the debugger run)-->spin_unlock_irq
If TASK_TRACED is not set earlier before arch_ptrace_stop on ia64
ptrace_notify code path, some signals would be delivered without
letting debugger run.. (i.e. PTRACED logica in get_signal_to_deliver
would be ignored totally!). These should cause the test case hang on
ia64. And x86 just works..
If you have any question , I would dig further..
Thanks,
Luming
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists