Received: by 2002:a05:6a10:a852:0:0:0:0 with SMTP id d18csp2626136pxy; Mon, 3 May 2021 04:38:04 -0700 (PDT) X-Google-Smtp-Source: ABdhPJye6oQBY48F3YWmRHn1Wma37MpxiNfPjjhoVFSLRS+Bc9RYR1vbJjn5FMM/v1CplDHGQ+Sz X-Received: by 2002:a05:6402:3584:: with SMTP id y4mr19639334edc.208.1620041884545; Mon, 03 May 2021 04:38:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1620041884; cv=none; d=google.com; s=arc-20160816; b=q+mkU3soTLMbvmyzLDMyFN8+SmMKW2BR11nLDi+Kcobk/1budHyN8oZaPBdQjZcHzp nXudSD0Vm/C1OurcYovhw5NQOr7FV6MJ9mxZj7gE142ipdasAy8URlMcgbPc/a5+Ioth UaGL482rVdUWphtq/L8SfWhSCJGmr4IBTMGemDARYMmZGW1dyRaG0qX7zDmRACqPbZQW r89t5xzJf6Om0NfK56tl5UFunLvMgstBMFlmsVHwGdU5yEDyQh9ZMBmX35zYxi/VtMZB RCErBjfgkcMtebPxNAx5zjOPkJUOegIsjwi+OgBhesLgfD04GKTBTrJByCQXdfbDdJYy T1ag== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=zb44HAcS7Q39R5ZEWWQpqDzpP8Cyw6/NAWOVD2gXy2o=; b=aDU9YIHXHdrQ6Dp7ZU9KQtX9ULeaKnwy01soSRsBV4cMGB7UlZjVFBJsks6MD98vZk mLMB1sno7kCnjn91d6I0/eu7srx0HmbqDLGyEA+FPgLisJZ95dC1LXI5nOWNgGqCx1wY wbf7QVLYdVgleA7mZPYAkbiSoIKHk+s/yar3XO+PR7HaPgfjhpoY1eK8i7FaNfF4nksJ 06nCRTswsovsXf5YfgXMFlmYwDYnowdlz75iQnyzXCa5t+p/N97b4tPX8ZIUdwZEAWqs qJGc0K07VnE0TzcrBZ+RuOmyVgnv7wkPLaA+O4rWp20xlFROOKWXd2PIfnbO2ctsi7c5 TO0w== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r15si9735334edd.83.2021.05.03.04.37.40; Mon, 03 May 2021 04:38:04 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233431AbhECK4k (ORCPT + 99 others); Mon, 3 May 2021 06:56:40 -0400 Received: from foss.arm.com ([217.140.110.172]:39370 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233259AbhECK4j (ORCPT ); Mon, 3 May 2021 06:56:39 -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 74063ED1; Mon, 3 May 2021 03:55:45 -0700 (PDT) Received: from [192.168.178.6] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 2B9463F718; Mon, 3 May 2021 03:55:43 -0700 (PDT) Subject: Re: [PATCH v3] sched: Fix out-of-bound access in uclamp To: Vincent Guittot , Quentin Perret Cc: Ingo Molnar , Peter Zijlstra , Juri Lelli , Steven Rostedt , Ben Segall , Mel Gorman , Daniel Bristot de Oliveira , Qais Yousef , Android Kernel Team , linux-kernel , Patrick Bellasi References: <20210430151412.160913-1-qperret@google.com> From: Dietmar Eggemann Message-ID: <562004ff-9f60-bf37-df4c-547415ae2cd5@arm.com> Date: Mon, 3 May 2021 12:55:34 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 30/04/2021 17:27, Vincent Guittot wrote: > On Fri, 30 Apr 2021 at 17:14, Quentin Perret wrote: >> >> Util-clamp places tasks in different buckets based on their clamp values >> for performance reasons. However, the size of buckets is currently >> computed using a rounding division, which can lead to an off-by-one >> error in some configurations. >> >> For instance, with 20 buckets, the bucket size will be 1024/20=51. A >> task with a clamp of 1024 will be mapped to bucket id 1024/51=20. Sadly, >> correct indexes are in range [0,19], hence leading to an out of bound >> memory access. >> >> Clamp the bucket id to fix the issue. >> >> Fixes: 69842cba9ace ("sched/uclamp: Add CPU's clamp buckets refcounting") >> Suggested-by: Qais Yousef >> Signed-off-by: Quentin Perret > > Reviewed-by: Vincent Guittot I forgot that config UCLAMP_BUCKETS_COUNT is in range 5 ... 20. So the error is bound to [-2 ... 5] (13/79, 20/51). I agree that we can live with that. Reviewed-by: Dietmar Eggemann >> --- >> Changes in v3: >> - Keep rounding div to improve fairness (Vincent) >> --- >> kernel/sched/core.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/kernel/sched/core.c b/kernel/sched/core.c >> index 98191218d891..c12ec648423e 100644 >> --- a/kernel/sched/core.c >> +++ b/kernel/sched/core.c >> @@ -928,7 +928,7 @@ DEFINE_STATIC_KEY_FALSE(sched_uclamp_used); >> >> static inline unsigned int uclamp_bucket_id(unsigned int clamp_value) >> { >> - return clamp_value / UCLAMP_BUCKET_DELTA; >> + return min_t(unsigned int, clamp_value / UCLAMP_BUCKET_DELTA, UCLAMP_BUCKETS - 1); >> } >> >> static inline unsigned int uclamp_none(enum uclamp_id clamp_id) >> -- >> 2.31.1.527.g47e6f16901-goog >>