From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-12.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2172BC55178 for ; Tue, 27 Oct 2020 15:23:39 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D1B9E2064B for ; Tue, 27 Oct 2020 15:23:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1603812218; bh=sLuJdl4lodoqFsG4UXG02/750QkLsgLur3NhU0yisbI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=ynXMAda9rEmbMoTiNKnPnLs/Ik9kwaiZrJ0+FCkL49/BjVu9y3d9AzQ4Z/Xpu34/3 FVtS6PxABmWtmEE+OvtqmLIiVPKYThI0Jv8hgwa8OoW+44XdncBHnweTsZLowpfgCV kSP+zrcWaK5Vsy26w9ux7c4mf4Uf+J2NZTyBmsT8= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1797453AbgJ0PXh (ORCPT ); Tue, 27 Oct 2020 11:23:37 -0400 Received: from mail.kernel.org ([198.145.29.99]:36104 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1797074AbgJ0PV3 (ORCPT ); Tue, 27 Oct 2020 11:21:29 -0400 Received: from localhost (83-86-74-64.cable.dynamic.v4.ziggo.nl [83.86.74.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id B816B22275; Tue, 27 Oct 2020 15:21:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1603812089; bh=sLuJdl4lodoqFsG4UXG02/750QkLsgLur3NhU0yisbI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ETBrtVPyk6VJZs/NbVyRzvfvvzDMGPkYLan0XiWNfCO4tj6OMpMZiuDSNKTlXq5We 50UwITlZVbFvngCJQm1alzzzN7M5f9G/uBk0fsnAt7ELbX2AKJuHnJ3ng8VCVmgc5K /r+Xz7G1TrAfyP2oqcJ+/I4MTHWimm8relmUuxZc= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Lukasz Luba , "Peter Zijlstra (Intel)" , Valentin Schneider , Sasha Levin Subject: [PATCH 5.9 089/757] sched/fair: Fix wrong negative conversion in find_energy_efficient_cpu() Date: Tue, 27 Oct 2020 14:45:39 +0100 Message-Id: <20201027135454.727876389@linuxfoundation.org> X-Mailer: git-send-email 2.29.1 In-Reply-To: <20201027135450.497324313@linuxfoundation.org> References: <20201027135450.497324313@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Lukasz Luba [ Upstream commit da0777d35f47892f359c3f73ea155870bb595700 ] In find_energy_efficient_cpu() 'cpu_cap' could be less that 'util'. It might be because of RT, DL (so higher sched class than CFS), irq or thermal pressure signal, which reduce the capacity value. In such situation the result of 'cpu_cap - util' might be negative but stored in the unsigned long. Then it might be compared with other unsigned long when uclamp_rq_util_with() reduced the 'util' such that is passes the fits_capacity() check. Prevent this situation and make the arithmetic more safe. Fixes: 1d42509e475cd ("sched/fair: Make EAS wakeup placement consider uclamp restrictions") Signed-off-by: Lukasz Luba Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Valentin Schneider Link: https://lkml.kernel.org/r/20200810083004.26420-1-lukasz.luba@arm.com Signed-off-by: Sasha Levin --- kernel/sched/fair.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 1a68a0536adda..51408ebd76c27 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -6594,7 +6594,8 @@ static int find_energy_efficient_cpu(struct task_struct *p, int prev_cpu) util = cpu_util_next(cpu, p, cpu); cpu_cap = capacity_of(cpu); - spare_cap = cpu_cap - util; + spare_cap = cpu_cap; + lsub_positive(&spare_cap, util); /* * Skip CPUs that cannot satisfy the capacity request. -- 2.25.1