Messages in this thread | | | Date | Thu, 12 May 2011 18:06:49 +0200 | From | Oleg Nesterov <> | Subject | Re: [PATCH 10/11] ptrace: move JOBCTL_TRAPPING wait to wait(2) and ptrace_check_attach() |
| |
On 05/12, Tejun Heo wrote: > > Hello, Oleg. > > On Wed, May 11, 2011 at 09:53:33PM +0200, Tejun Heo wrote: > > > As for ptrace_check_attach(), it can simply do wait_event(), we > > > only need to verify the caller is the tracer. No need to play with > > > lock/unlock/retry. > > > > > > What do you think? > > > > Hmmm... interesting. Yeah, the state is visible only through wait(2) > > and ptrace(2) and for wait(2) TRAPPING is as good as STOPPED/TRACED > > and we can wait all we want in ptrace_check_attach(). I'll think more > > about it but seems like a nice idea. > > Eh, problem. Please consider the following scenario. > > * A task is in TASK_STOPPED. current->exit_code contains zero. > > * Tracer seizes the task which triggers TRAPPING. > > * Tracer wait(2)s which sees TRAPPING but tracee->exit_code is still > zero.
At first glance, this is easy to fix. do_signal_stop() can set ->exit_code unconditionally as it did before.
> I think retrying and ensuring that tracee is in the expected state > after going through the regular trapping procedure is better way to > handle this. Bypassing wait(2) seems smart and simple but it entails > much more subtleties than simple stupid waiting/retrying.
Agreed. But this wait_event(!TRAPPING) logic has a lot of subtleties too.
Oleg.
| |