Messages in this thread |  | | From | David Mosberger <> | Date | Fri, 7 Sep 2001 08:35:31 -0700 | Subject | Re: [patch] proposed fix for ptrace() SMP race |
| |
>>>>> 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/
|  |