Peter Zijlstra <[email protected]> writes:
> On Thu, Apr 21, 2022 at 09:55:51PM +0200, Peter Zijlstra wrote:
>> On Thu, Apr 21, 2022 at 12:26:44PM -0500, Eric W. Biederman wrote:
>> > Peter Zijlstra <[email protected]> writes:
>> >
>> > > --- a/kernel/ptrace.c
>> > > +++ b/kernel/ptrace.c
>> > > @@ -288,7 +288,7 @@ static int ptrace_check_attach(struct ta
>> > > }
>> > > __set_current_state(TASK_RUNNING);
>> > >
>> > > - if (!wait_task_inactive(child, TASK_TRACED) ||
>> > > + if (!wait_task_inactive(child, TASK_TRACED|TASK_FREEZABLE) ||
>> > > !ptrace_freeze_traced(child))
>> > > return -ESRCH;
>> >
>> > Do we mind that this is going to fail if the child is frozen
>> > during ptrace_check_attach?
>>
>> Why should this fail? wait_task_inactive() will in fact succeed if it is
>> frozen due to the added TASK_FREEZABLE and some wait_task_inactive()
>> changes elsewhere in this patch.
>
> These:
I had missed that change to wait_task_inactive.
Still that change to wait_task_inactive fundamentally depends upon the
fact that we don't care about the state we are passing into
wait_task_inactive. So I think it would be better to simply have a
precursor patch that changes wait_task_inactive(child, TASK_TRACED) to
wait_task_inactive(child, 0) and say so explicitly.
Eric