| From | Valentin Schneider <> | Subject | Re: [PATCH v4 14/19] sched, lockdep: Annotate ->pi_lock recursion | Date | Thu, 29 Oct 2020 16:27:16 +0000 |
| |
On 23/10/20 11:12, Peter Zijlstra wrote: > @@ -2617,6 +2618,20 @@ void sched_set_stop_task(int cpu, struct > sched_setscheduler_nocheck(stop, SCHED_FIFO, ¶m); > > stop->sched_class = &stop_sched_class; > + > + /* > + * The PI code calls rt_mutex_setprio() with ->pi_lock held to > + * adjust the effective priority of a task. As a result, > + * rt_mutex_setprio() can trigger (RT) balancing operations, > + * which can then trigger wakeups of the stop thread to push > + * around the current task. > + * > + * The stop task itself will never be part of the PI-chain, it > + * never blocks, therefore that ->pi_lock recursion is safe.
Isn't it that the stopper task can only run when preemption is re-enabled, and the ->pi_lock is dropped before then?
If we were to have an SCA-like function that would kick the stopper but "forget" to release the pi_lock, then we would very much like lockdep to complain, right? Or is that something else entirely?
> + * Tell lockdep about this by placing the stop->pi_lock in its > + * own class. > + */ > + lockdep_set_class(&stop->pi_lock, &stop_pi_lock); > } > > cpu_rq(cpu)->stop = stop;
|