linux-kernel - Re: [PATCH 0/4] cpumask: add missing API and simplify 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] [day] [month] [year] [list]

Message-ID: <7681f92a-047b-4722-8cac-2f269ae10a45@arm.com>
Date: Thu, 24 Apr 2025 18:22:45 +0100
From: James Morse <james.morse@....com>
To: Yury Norov <yury.norov@...il.com>,
 Reinette Chatre <reinette.chatre@...el.com>
Cc: Tony Luck <tony.luck@...el.com>, Thomas Gleixner <tglx@...utronix.de>,
 Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
 Dave Hansen <dave.hansen@...ux.intel.com>, "H. Peter Anvin" <hpa@...or.com>,
 Rasmus Villemoes <linux@...musvillemoes.dk>, x86@...nel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/4] cpumask: add missing API and simplify
 cpumask_any_housekeeping()

Hi Reinette, Yury,

On 24/04/2025 04:11, Yury Norov wrote:
> On Wed, Apr 23, 2025 at 02:27:46PM -0700, Reinette Chatre wrote:
>> On 4/7/25 8:38 AM, Yury Norov wrote:
>>> From: Yury Norov [NVIDIA] <yury.norov@...il.com>
>>>
>>> cpumask library missed some flavors of cpumask_any_but(), which makes
>>> users to workaround it by using less efficient cpumask_nth() functions.
>>>
>>> Yury Norov (4):
>>>   relax cpumask_any_but()
>>>   find: add find_first_andnot_bit()
>>>   cpumask_first_andnot
>>>   resctrl
>>
>> (sidenote: above list of patch subjects do not match the series)
>>
>> Thank you very much for doing this work. This simplifies resctrl code
>> significantly. I do have a couple of comments that you will find in
>> the individual patches. 
> 
> Sure, glad to see you like it.
>  
>> Regarding upstreaming I would like to propose that the upstreaming of
>> this work be split so that resctrl changes do not go upstream
>> via separate trees during this cycle. I am ok with delaying the resctrl
>> portion of this work for a cycle. This is because we hope to include a
>> huge change [1] to resctrl that includes the code modified in this series.
>> Having these two changes meet during merge window will be inconvenient
>> for maintainers involved. If you require a user to upstream these new
>> helpers then another possibility is to upstream this work via the tip repo
>> if that is ok with x86 maintainers so that that huge resctrl patch is created on
>> top if this work.

> I can move all the patches with my branch (bitmap-for-next) if you ack
> the restcl part, or let resctl folks (you, I guess) take over the series.

> Or we can split it, so I'll move generic part myself, and you'll move
> the last patch.

That would mean co-ordinating the order those get merged in, which is extra work for the
relevant maintainers.

The patch that moves all the code is easy to regenerate as this series doesn't add any new
functions. Ideally any series touching resctrl in the same merge window would also go via
tip - but it would also possible to rebase onto an immutable branch. (needed if
bitmap-for-next also has dependencies/conflicts on these patches)

I think its easier for the tip folk if I rebase onto this once as/when its got all the
needed tags.

Thanks,

James