linux-kernel - Re: [PATCH v2 20/23] sched/cache: Add user control to adjust the parameters of cache-aware scheduling

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <fecf066c-9213-4118-940c-88dbc209f9c4@intel.com>
Date: Wed, 21 Jan 2026 23:38:33 +0800
From: "Chen, Yu C" <yu.c.chen@...el.com>
To: Yangyu Chen <cyy@...self.name>
CC: Juri Lelli <juri.lelli@...hat.com>, Dietmar Eggemann
	<dietmar.eggemann@....com>, Steven Rostedt <rostedt@...dmis.org>, Ben Segall
	<bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>, Valentin Schneider
	<vschneid@...hat.com>, Madadi Vineeth Reddy <vineethr@...ux.ibm.com>, "Hillf
 Danton" <hdanton@...a.com>, Shrikanth Hegde <sshegde@...ux.ibm.com>,
	"Jianyong Wu" <jianyong.wu@...look.com>, Tingyin Duan
	<tingyin.duan@...il.com>, Vern Hao <vernhao@...cent.com>, Vern Hao
	<haoxing990@...il.com>, Len Brown <len.brown@...el.com>, Aubrey Li
	<aubrey.li@...el.com>, Zhao Liu <zhao1.liu@...el.com>, Chen Yu
	<yu.chen.surf@...il.com>, Adam Li <adamli@...amperecomputing.com>, Aaron Lu
	<ziqianlu@...edance.com>, Tim Chen <tim.c.chen@...el.com>,
	<linux-kernel@...r.kernel.org>, Tim Chen <tim.c.chen@...ux.intel.com>, Peter
 Zijlstra <peterz@...radead.org>, "Gautham R . Shenoy"
	<gautham.shenoy@....com>, K Prateek Nayak <kprateek.nayak@....com>, Vincent
 Guittot <vincent.guittot@...aro.org>, "Ingo Molnar" <mingo@...hat.com>
Subject: Re: [PATCH v2 20/23] sched/cache: Add user control to adjust the
 parameters of cache-aware scheduling

Hi Yangyu,

On 1/21/2026 11:21 PM, Yangyu Chen wrote:
> 
> 
> On 4/12/2025 07:07, Tim Chen wrote:

[ ... ]

>> +    scale = get_sched_cache_scale(256);
> 
> Hi Tim Chen and Chen Yu,
> 
> There's an integer overflow here. Since the unit of LLC size is bytes, 
> you have a 256-scale unit. For a typical LLC size of 32M, you calculate 
> 32M multiplied by 256, which equals 8GB. This value exceeds the maximum 
> integer value (2GB, INT_MAX), resulting in an integer overflow.
> 
> I think such function should be use u64. Below is my patch:
> 

Thanks very much for the investigation, Jianyong previously also
mentioned this issue
https://lore.kernel.org/all/SI2PR04MB49317BA503E9C8A381956D6AE38CA@SI2PR04MB4931.apcprd04.prod.outlook.com/
we will fix the issue accordingly.


> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 205208f061bb..bcafb3c2b369 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -1226,20 +1226,20 @@ static int llc_id(int cpu)
>       return llc;
>   }
> 
> -static inline int get_sched_cache_scale(int mul)
> +static inline u64 get_sched_cache_scale(int mul)
>   {
>       if (!llc_aggr_tolerance)
>           return 0;
> 
>       if (llc_aggr_tolerance == 100)
> -        return INT_MAX;
> +        return ULLONG_MAX;
> 
>       return (1 + (llc_aggr_tolerance - 1) * mul);
>   }
> 
>   static bool exceed_llc_capacity(struct mm_struct *mm, int cpu)
>   {
> -    unsigned int llc, scale;
> +    unsigned long long llc, scale;

I suppose we only need to change llc to u64, and not change
scale, because (llc * scale) would be converted to u64 anyway.

thanks,
Chenyu