Re: [PATCH] ptrace: fix ptrace_unfreeze_traced() race with rt-lock

[Oleg Nesterov <oleg@redhat.com>]

On 11/02, Sebastian Andrzej Siewior wrote:
>
> On 2020-11-02 16:50:01 [+0100], Oleg Nesterov wrote:
> >
> >  static void ptrace_unfreeze_traced(struct task_struct *task)
> >  {
> > -	if (task->state != __TASK_TRACED)
> > -		return;
> > +	bool frozen = true;
>
> Is this okay for !PREEMPT_RT or is this considered as an important
> fast-path on !PREEMPT_RT?

I do not know how can ptrace_unfreeze_traced() check both ->state and
->saved_state lockless.

If it is possible then task_is_traced() can avoid pi_lock too?

> >  	WARN_ON(!task->ptrace || task->parent != current);
> >
> > @@ -207,12 +206,19 @@ static void ptrace_unfreeze_traced(struct task_struct *task)
> >  	 * Recheck state under the lock to close this race.
> >  	 */
> >  	spin_lock_irq(&task->sighand->siglock);
> > -	if (task->state == __TASK_TRACED) {
> > -		if (__fatal_signal_pending(task))
> > -			wake_up_state(task, __TASK_TRACED);
> > -		else
> > -			task->state = TASK_TRACED;
> > -	}
> > +
> > +	raw_spin_lock(&task->pi_lock);
>
> I think this got mentioned in the other emails but this requires irqsave
> because the above (siglock) does not disable interrupts on RT.

OK, I'll send V2 in a minute.

> This `saved_state' is only used for RT so it might make sense to avoid
> the PI-lock on non-RT.

The same is true for ptrace_freeze_traced(), we can probably add ifdef's
but I am not sure this makes sense...

Oleg.