Re: Compat 32-bit syscall entry from 64-bit task!?

[Denys Vlasenko]

On Thu, Jan 26, 2012 at 11:31 AM, Jamie Lokier <jamie@xxxxxxxxxxxxx> wrote:
> Indan Zupancic wrote:
>> On Thu, January 26, 2012 02:08, Jamie Lokier wrote:
>> > Is it disambiguated by PTRACE_EVENT_EXEC happening before the execve
>> > returns, and you knowing the TID always changes to the PID?  I haven't
>> > yet checked which TID gets the PTRACE_EVENT_EXEC event, but if it's
>> > not the old one, perhaps that could be changed.
>>
>> Please don't ever change the behaviour of PTRACE_EVENT_EXEC, it's
>> barely documented already, but if if ever changes it will be also
>> unreliable.
>>
>> It's still unclear if the PTRACE_EVENT_EXEC comes before or after
>> or instead of the post-execve ptrace event.

Denis <- confused.
Was ist das "post-execve ptrace event"? I know no such thing.
I know about PTRACE_EVENT_EXEC, and "post-execve SIGTRAP".


>> I guess before, but
>> can I count on that? If it is after then I get a stray weird
>> execve event that messes up the system call cadence.
>
> It should be *sent* before because the exec steps must finish before
> the execve() syscall "returns".
>
> I'm not sure if the events are guaranteed to be received in the same
> order as they are sent.

All ptrace stops (events and other stops) are synchronous.
Tracee stops, tracer notices it, tracer restarts tracee,
and only after this tracee can generate next event.
Therefore ptrace stops can't get reordered.

-- 
vda
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/