On 07/24/20 11:12, Peter Zijlstra wrote: > On Thu, Jul 16, 2020 at 12:03:47PM +0100, Qais Yousef wrote: > > I've trimmed the Changelog to read like:
+1 Should we mention the ordering issue too? Or maybe I misinterpreted the 'Possible unsafe locking scenario' part? > > --- > Subject: sched/uclamp: Fix a deadlock when enabling uclamp static key > From: Qais Yousef <[email protected]> > Date: Thu, 16 Jul 2020 12:03:47 +0100 > > From: Qais Yousef <[email protected]> > > The following splat was caught when setting uclamp value of a task: > > BUG: sleeping function called from invalid context at > ./include/linux/percpu-rwsem.h:49 > > cpus_read_lock+0x68/0x130 > static_key_enable+0x1c/0x38 > __sched_setscheduler+0x900/0xad8 > > Fix by ensuring we enable the key outside of the critical section in > __sched_setscheduler() > > Fixes: 46609ce22703 ("sched/uclamp: Protect uclamp fast path code with static > key") > Signed-off-by: Qais Yousef <[email protected]> > Signed-off-by: Peter Zijlstra (Intel) <[email protected]> > Link: https://lkml.kernel.org/r/[email protected] > --- > > And placed this patch first in the series > > That said; don't we have a slight problem with enabling the key late > like this? It means the uclamp will not actually take effect immediately > and we'll have to wait for the next context switch ... whenever that > might be. The enabling is racy inherently. Your suggestion below is better though. I should have scrolled more screens up! > > Should we not have enabled the key early, instead of late? > > something like so perhaps? This should work, but you'll need to sprinkle ifdef around the key. Or move it to uclamp_validate() --- diff --git a/kernel/sched/core.c b/kernel/sched/core.c index e1578c3ad40c..cd3b7a25ac59 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -1345,6 +1345,21 @@ static int uclamp_validate(struct task_struct *p, if (upper_bound > SCHED_CAPACITY_SCALE) return -EINVAL; + /* + * Enable uclamp static key outside the critical section of + * __sched_setschuler(). + * + * static_branch_enable() will hold cpu_hotplug_lock; if done from + * critical section, __setscheduler_uclamp(), which holds other locks + * (rq->lock namely), it could lead to deadlock scenarios as both are + * popular locks and could be acquired from different paths in + * different orders. + * + * Besides cpu_hotplug_lock could sleep, which is not allowed inside + * the critical section of __sched_setscheduler(). + */ + static_branch_enable(&sched_uclamp_used); + return 0; } @@ -1378,8 +1393,6 @@ static void __setscheduler_uclamp(struct task_struct *p, if (likely(!(attr->sched_flags & SCHED_FLAG_UTIL_CLAMP))) return; - static_branch_enable(&sched_uclamp_used); - if (attr->sched_flags & SCHED_FLAG_UTIL_CLAMP_MIN) { uclamp_se_set(&p->uclamp_req[UCLAMP_MIN], attr->sched_util_min, true);
