Received: by 2002:a25:e74b:0:0:0:0:0 with SMTP id e72csp2034841ybh; Fri, 24 Jul 2020 02:47:29 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzWFOXtp9yOf6AGFnFTho/J4CDh6+KGi9wiVt1wetyP49n32Ixgq2bGyM+7OR3gAapv86DN X-Received: by 2002:a05:6402:888:: with SMTP id e8mr8414067edy.210.1595584048860; Fri, 24 Jul 2020 02:47:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1595584048; cv=none; d=google.com; s=arc-20160816; b=xhZDHP6c/ltKXppwwYHgjPPT1ZYuUCmJjRygmE5a9x3N5GwWspxr8dk0IS+q/va/KN I5d/a9J4m9VB2OqPkXbHs1j09+3amcCPJbVneyEN0KkUH74l1sekM6Az6+mV2x5S7RhH XFJCS87md8tjvTCHIP8WTYMMVzYdThRSNWnkOE072E1DER4FJTSkxN+7oJIZ7CXaLRvR QrBhQQGpiS4IPfCY5pxo+tjRApCT+Y8Mh2qpgOUoLpuaVaxmi00FcKPVrsUn3JJ6kbvr JlW3+nY97Vc2vllC1RhAzE8E9164wT+FJUpQ1VByWcqEnkK3AJukR7priv7SZms2yfji FQ1A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=UE73hLy+RK6J4Z1Yop03n2+ReoVBWrdV8ZxgfVMW8Mc=; b=rYsCmVlx9SN/wVlTjwxiBMFFdrXuKs3muOwAtrE0BmOekETTs21tcSYmh0KU3hlIHz uZAYa+069wVhMQSpBh17oqKgaR0FYtxwIOa1p3kcriiCzIlneZjGQUuBrez9/3LL2Iv0 nD+1eJLzcH+6u7GYWsXP2WwXpIheKEPE5QUCcKhyPABAdY7XnLxrXRHJb2Q1KKfcVKgj VT1Mj6Y50IRSM0RcwHi7wIYDgcnAbcJegVAPH8M6qqgmpmN6kC9GpD6jsuM91M9bwTxZ XuskQ1OXWUBCS7dosM+1hbdK24z7SIWbgtaPOh0wf0xmiViQzDXyWClU8/f9R5HVh358 DbEw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y13si227162edp.149.2020.07.24.02.47.05; Fri, 24 Jul 2020 02:47:28 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726800AbgGXJqz (ORCPT + 99 others); Fri, 24 Jul 2020 05:46:55 -0400 Received: from foss.arm.com ([217.140.110.172]:59120 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726114AbgGXJqz (ORCPT ); Fri, 24 Jul 2020 05:46:55 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id A0430D6E; Fri, 24 Jul 2020 02:46:54 -0700 (PDT) Received: from e107158-lin.cambridge.arm.com (e107158-lin.cambridge.arm.com [10.1.195.21]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id F2DE93F66E; Fri, 24 Jul 2020 02:46:52 -0700 (PDT) Date: Fri, 24 Jul 2020 10:46:50 +0100 From: Qais Yousef To: Peter Zijlstra Cc: Ingo Molnar , Doug Anderson , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Patrick Bellasi , Chris Redpath , Lukasz Luba , linux-kernel@vger.kernel.org Subject: Re: [PATCH v7 3/3] sched/uclamp: Fix a deadlock when enabling uclamp static key Message-ID: <20200724094650.hgya5j7i7lbhrocy@e107158-lin.cambridge.arm.com> References: <20200716110347.19553-1-qais.yousef@arm.com> <20200716110347.19553-4-qais.yousef@arm.com> <20200724091244.GX10769@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200724091244.GX10769@hirez.programming.kicks-ass.net> User-Agent: NeoMutt/20171215 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 > Date: Thu, 16 Jul 2020 12:03:47 +0100 > > From: Qais Yousef > > 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 > Signed-off-by: Peter Zijlstra (Intel) > Link: https://lkml.kernel.org/r/20200716110347.19553-4-qais.yousef@arm.com > --- > > 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);