linux-kernel - Re: [RFC PATCH] cpumask: Implement "random" version of cpumask_any

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <Z4T0gYnl9Xzhd+2g@visitorckw-System-Product-Name>
Date: Mon, 13 Jan 2025 19:09:53 +0800
From: Kuan-Wei Chiu <visitorckw@...il.com>
To: I Hsin Cheng <richard120310@...il.com>
Cc: yury.norov@...il.com, linux@...musvillemoes.dk, jserv@...s.ncku.edu.tw,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] cpumask: Implement "random" version of
 cpumask_any_but()

On Mon, Jan 13, 2025 at 06:27:26PM +0800, I Hsin Cheng wrote:
> On Mon, Jan 13, 2025 at 06:13:07PM +0800, Kuan-Wei Chiu wrote:
> > Hi I Hsin,
> > 
> > On Mon, Jan 13, 2025 at 02:18:39PM +0800, I Hsin Cheng wrote:
> > > Original implementation of "cpumask_any_but()" isn't actually random as
> > > the comment claims itself to be. It's behavior is in fact to select the
> > > first cpu in "mask" which isn't equal to "cpu".
> > > 
> > > Re-implement the function so we can choose a random cpu by randomly
> > > select the value of "n" and choose the nth cpu in "mask"
> > > 
> > This patch may slow down the efficiency of cpumask_any_but(). Are there
> > any in-tree users of cpumask_any_but() that require it to return a
> > truly random id, or benefit from such behavior?
> 
> Hi Kuan-Wei,
> 
> Thanks for your review ! Yes indeed it may slow down the efficiency
> abit.
> 
> However there are some use cases I think randomness is important
> such as "dl_task_offline_migration()" under kernel/sched/deadline.c ,
> where the operation of cpu picking shouldn't favor certain cpu too much.
> 
> Also "select_task_rq()" utitlize "cpumask_any()" to pick cpu, it doesn't
> need to be perfectly random, but neither should it only favor certain
> cpu.
> 
> What do you think?
>

If a true random number isn't needed, could next_pseudo_random32() be
used instead for better efficiency?

I'm not familiar with the scheduler, but if there are only one or two
scheduler use cases, would you consider creating a new
cpumask_random_but() API and converting those specific cases to use it?
In this case, the patch should also be CC'd to scheduler developers.
Additionally, you should explain the benefits of this approach in the
patch description.

Regards,
Kuan-Wei