[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4CF3AF35.4050108@kernel.org>
Date: Mon, 29 Nov 2010 14:48:37 +0100
From: Tejun Heo <tj@...nel.org>
To: Oleg Nesterov <oleg@...hat.com>
CC: roland@...hat.com, linux-kernel@...r.kernel.org,
torvalds@...ux-foundation.org, akpm@...ux-foundation.org,
"@sisk.plpavel@....cz"@htj.dyndns.org,
"Jan Kratochvil \"" <jan.kratochvil@...hat.com>
Subject: Re: [PATCH 09/14] ptrace: clean transitions between TASK_STOPPED
and TRACED
Hello, Oleg.
On 11/28/2010 09:25 PM, Oleg Nesterov wrote:
> This adds another user-visible change, this time it is more serious.
> Again, I do not claim it breaks ptrace, just I do not know.
>
>> @@ -204,6 +202,19 @@ int ptrace_attach(struct task_struct *task)
>> __ptrace_link(task, current);
>> send_sig_info(SIGSTOP, SEND_SIG_FORCED, task);
>>
>> + /*
>> + * If the task is already STOPPED, set GROUP_STOP_PENDING and
>> + * kick it so that it transits to TRACED. This is safe as
>> + * both transitions in and out of STOPPED are protected by
>> + * siglock.
>> + */
>> + spin_lock(&task->sighand->siglock);
>> + if (task_is_stopped(task)) {
>> + task->group_stop |= GROUP_STOP_PENDING;
>> + signal_wake_up(task, 1);
>
> OK. Now we have a window if the tracer attaches to the stopped task.
>
> Say,
>
> child = fork()
>
> if (!child)
> return child_do_something();
>
> kill(child, SIGSTOP);
> wait(); // <--- ensures it is stopped
>
> ptrace(PTRACE_ATTACH, child);
>
> assert(ptrace(PTRACE_WHATEVER, child) == 0);
>
> Currently this code is correct. With this patch the assertion above
> can fail, the child may be running, changing its state from STOPPED
> to TRACED.
Hmmm... rather convoluted, but yeap. I can update the code to wait
for stopped -> traced transition to complete, so that the transition
is hidden from userland. How does that sound to you?
>> @@ -1812,7 +1817,13 @@ static int do_signal_stop(int signr)
>>
>> spin_lock_irq(¤t->sighand->siglock);
>> } else
>> - ptrace_stop(current->exit_code, CLD_STOPPED, 0, NULL);
>> + ptrace_stop(current->group_stop & GROUP_STOP_SIGMASK,
>> + CLD_STOPPED, 0, NULL);
>> +
>> + if (current->group_stop & GROUP_STOP_PENDING) {
>> + WARN_ON_ONCE(!(current->group_stop & GROUP_STOP_SIGMASK));
>> + goto retry;
>
> This doesn't look right even without ptrace.
>
> Suppose we have to threads, T1 and T2, both stopped, SIGNAL_STOP_STOPPED
> is set.
>
> SIGCONT wakes them up.
>
> To simplify the discussion, suppose that T1 takes a long preemption
> when it returns from schedule(), right before it takes ->siglock again.
>
> T2 sends CLD_CONTINUED to parent and dequeues another SIGSTOP. It
> initiates another group stop, sees T1 as running, and stops with
> ->group_stop_count == 1. Now we are waiting for T1 which should
> participate.
>
> Finally T1 resumes and sees GROUP_STOP_PENDING. It goes to 'retry:'
> and stops, but nobody notifies the parent ang ->group_stop_count is
> still non-zero.
Good point. I'll think about how the problem can be solved. Maybe
the retry and pending states need to be separated.
Thanks.
--
tejun
--
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