linux-kernel - Re: [RFC PATCH] sched: Fix integer overflow issue of cpu weight delta

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: <Z06mz0GwBu2UP2bt@vaxr-BM6660-BM6360>
Date: Tue, 3 Dec 2024 14:35:59 +0800
From: I Hsin Cheng <richard120310@...il.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: mingo@...hat.com, juri.lelli@...hat.com, vincent.guittot@...aro.org,
	dietmar.eggemann@....com, rostedt@...dmis.org, bsegall@...gle.com,
	mgorman@...e.de, vschneid@...hat.com, linux-kernel@...r.kernel.org,
	jserv@...s.ncku.edu.tw
Subject: Re: [RFC PATCH] sched: Fix integer overflow issue of cpu weight delta

On Mon, Dec 02, 2024 at 11:41:03AM +0100, Peter Zijlstra wrote:
> On Mon, Dec 02, 2024 at 06:13:44PM +0800, I Hsin Cheng wrote:
> 
> > I think there's one point to concern, do we have a fixed range of
> > "tg_weight()" ? 
> 
> kernel/sched/fair.c:__sched_group_set_shares()
> 
>   shares = clamp(shares, scale_load(MIN_SHARES), scale_load(MAX_SHARES));
> 
>   if (tg->shares == shares)
>   	return 0;
> 
>   tg->shares = shares;

Thanks for clarify this ! So tg->shares should be clamped between (1 <<
1) and (1 << 18), No overflow issue should happen as long as we're sure
the value of "shares" won't exceed the range.

Then why don't we make the type of "tg->shares" to "int" or "unsigned"?
so the size of this member can be shrink. Is there any specific reason
to make "tg->shares" as "unsigned long" ? at the same time I want to ask
does "tg->shares" basically means the same as the task group's weight?

I didn't see any explanation about it in the documentation, or I
might've missed it.

Best regards,
Richard Cheng.