>>>>> On Fri, 7 Sep 2001 15:28:58 +0200, Andrea Arcangeli <andrea@suse.de> 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.
--david
-
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/
This archive was generated by hypermail 2b29 : Fri Sep 07 2001 - 21:00:41 EST