lkml.org 
[lkml]   [2011]   [May]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH 04/11] ptrace: implement PTRACE_INTERRUPT
On Wed, May 11, 2011 at 09:22, Tejun Heo <tj@kernel.org> wrote:
> Hey,
>
> On Wed, May 11, 2011 at 02:23:44PM +0200, Denys Vlasenko wrote:
>> I understand this. I am trying to understand what feature are you trying
>> to provide to userland, or what problematic race scenario you are trying
>> to make resolve-able *in userland* by making "stop" and "cont"
>> notifications sticky wrt GETSIGINFO. I just don't see this scenario.
>
> If you still don't see how events can get lost, I'm afraid I can't
> explain any better.  You're repeating that exit_code can record the
> event until it's fetched but it doesn't queue and any trap will
> overwrite it and debuggers don't have to call GETSIGINFO after each
> trap - it only has to do so for signal delivery, group stop and
> INTERRUPT trap.  So, it can just look at the exit_code (which doesn't
> indicate continuation) and let tracee return to userland.
>
> Maybe I'm horribly confused.  Oleg, am I?

If a process issues PTRACE_INTERRUPT, it just wants the target process
to stop. Presumably it doesn't really care _why_, as long as it
doesn't introduce spurious effects visible to the target. As such, if
the process stops on its own due to some other trap, that ought to be
good enough, right? Is there really a need for a trap that will be
reliably echoed back to the trapping process?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2011-05-11 18:23    [W:0.195 / U:0.232 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site