Re: [PATCH v2] ptrace: fix ptrace vs tasklist_lock race on PREEMPT_RT.

[Eric W. Biederman]

Peter Zijlstra <peterz@xxxxxxxxxxxxx> writes:

> On Fri, Apr 08, 2022 at 10:06:30PM +0200, Peter Zijlstra wrote:
>
>> I'll ponder if wait_task_inactive() can simplify things..
>
> This,.. so ptrace_check_attach(), which does ptrace_freeze_traced()
> already does wait_task_inactive(), but on the 'wrong' side of things.
>
> AFAICT, if we move that up, we're almost there, except that opens up a
> detach+attach race. That could be fixed by doing another
> wait_task_inactive(), but we can't due to locking :/
>
> Let's see if I can make that work without making a mess of things.
> Because ensuring the task is stuck in schedule() makes the whole
> saved_state thing go away -- as you noted.

The code can perhaps synchronize on a bit using the the full locking and
then drop the locks and call the wait_task_inactive or whatever.

The challenge as I see it is after the traced task is inactive to allow
"wake_up_state(t, TASK_WAKEKILL)" on the traced task, have the traced
tasks state change to TASK_RUNNING and not allow the traced task to run
until what is today ptrace_unfreeze_task is called.

I just don't know how to get something stuck and not allow it to run.

Eric