linux-kernel - Re: [PATCH 0/3] Add and use get_cpu_cacheinfo

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]

Date: Mon, 3 Jun 2024 09:55:24 -0700
From: Reinette Chatre <reinette.chatre@...el.com>
To: Tony Luck <tony.luck@...el.com>, Greg Kroah-Hartman
	<gregkh@...uxfoundation.org>, Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>, Borislav Petkov <bp@...en8.de>
CC: Fenghua Yu <fenghua.yu@...el.com>, Maciej Wieczor-Retman
	<maciej.wieczor-retman@...el.com>, Peter Newman <peternewman@...gle.com>,
	James Morse <james.morse@....com>, Babu Moger <babu.moger@....com>, "Drew
 Fustini" <dfustini@...libre.com>, Dave Martin <Dave.Martin@....com>,
	<linux-kernel@...r.kernel.org>, <patches@...ts.linux.dev>
Subject: Re: [PATCH 0/3] Add and use get_cpu_cacheinfo_level()

Dear Maintainers,

On 5/31/24 12:57 PM, Tony Luck wrote:
> [get_maintainer.pl is vague about who owns <linux/cacheinfo.h>
>   to I've scattershooted some of the folks that committed changes
>   for this file]

Thank you to Andrew for picking up this series into the
mm-nonmm-unstable branch. I am not familiar with how patches flow
from this repo/branch but I expect that this inclusion will require some
high level coordination between the big repos since resctrl changes
usually flow upstream through x86/cache branch of tip and I
anticipate some conflicts and also needing to figure out how to deal
with this new dependency in planned resctrl changes.

As Tony mentioned upcoming resctrl changes depend on this new
include/linux/cacheinfo.h addition while some other planned
resctrl changes [2] will conflict with patch #2 and #3 of this series.

A previous change to include/linux/cacheinfo.h (commit
709c4362725a ("cacheinfo: Move resctrl's get_cache_id() to the
cacheinfo header file")) was able to accompany the resctrl
changes via x86/cache of tip. Could it be possible to repeat
such a patch flow?

Looking at mm-nonmm-unstable there is indeed one other pending
change that touches include/linux/cacheinfo.h ("cpumask: make
core headers including cpumask_types.h where possible"). I
confirmed that there is no conflict between it and patch #1
from this series, the two can be applied in any order. Of course,
this means nothing for any other changes to this file
that may arrive later during this cycle.

Could you please provide your guidance on how to achieve a smooth
upstream of this work?

Thank you

Reinette

[2] https://lore.kernel.org/lkml/20240321165106.31602-1-james.morse@arm.com/

> This helper function came up in discussion of the resctrl patches
> for Sub-NUMA Cluster (SNC) support. Reinette pointed out[1] that there
> are already two places where it would clean things up by avoiding
> open coding. The SNC patches will add two additional call sites.
> 
> So rather than have this jammed up as part of the SNC series, I'm
> posting it as a simple standalone cleanup.
> 
> Signed-off-by: Tony Luck <tony.luck@...el.com>
> 
> [1] https://lore.kernel.org/all/050c64b3-20b3-4db6-b782-f5124ebaab31@intel.com/
> 
> Tony Luck (3):
>    cacheinfo: Add function to get cacheinfo for a given (cpu, cachelevel)
>    x86/resctrl: Replace open code cacheinfo search in
>      pseudo_lock_region_init()
>    x86/resctrl: Replace open code cacheinfo search in
>      rdtgroup_cbm_to_size()
> 
>   include/linux/cacheinfo.h                 | 21 ++++++++++++++++-----
>   arch/x86/kernel/cpu/resctrl/pseudo_lock.c | 17 ++++++-----------
>   arch/x86/kernel/cpu/resctrl/rdtgroup.c    | 14 +++++---------
>   3 files changed, 27 insertions(+), 25 deletions(-)
> 
> 
> base-commit: 1613e604df0cd359cf2a7fbd9be7a0bcfacfabd0