[lkml]   [2001]   [Sep]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch] proposed fix for ptrace() SMP race
>>>>> On Fri, 7 Sep 2001 15:28:58 +0200, Andrea Arcangeli <> said:

Andrea> correct, I suggest to ignore SIGCONT as well while
Andrea> PT_PTRACED is set.

Do you really think it's acceptable? With your patch, you couldn't
SIGKILL or SIGCONT a task that happens to be ptraced. I certainly
would expect to be able to do this for a task that is being strace'd,
for example.

Also, other signals will still wake up the task. Yes, it won't get
very far as do_signal() will notify the parent instead, but still, the
task will run and that could be enough to create some race condition.

What about the other wakeup paths that I had mentioned? E.g., what if
the ptraced task is ptracing another task? Couldn't notify_parent()
end up waking up the task as well?

Andrea> Also when you restore the cpus_allowed you won't effectively
Andrea> wakup the task, it will just keep floating in the runqueue
Andrea> but we won't try to reschedule the other idle cpus it so
Andrea> it's broken.

Ah, that's a good point, thanks. Nothing that can't be fixed, though.

>> Hmmh, looking at ptrace() more closely, the entire locking
>> situation seems to be a bit confused. For example, what's
>> stopping wait4() from releasing the task structure just after
>> ptrace() released the tasklist_lock and before it checked
>> child->state?

Andrea> the get_task_struct()

Yes, I missed that.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:02    [W:0.038 / U:0.180 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site