Re: [PATCH] arm_mpam: resctrl: Catch and propagate error from get_cpu_cacheinfo_id()

From: Gavin Shan

Date: Mon Sep 14 2026 - 02:38:01 EST


Hi Yin,

On 9/14/26 4:25 PM, Yin Li wrote:
On 9/14/2026 2:14 PM, Gavin Shan wrote:
On 9/3/26 12:37 AM, Andre Przywara wrote:
get_cpu_cacheinfo_id() can fail, in which case it returns a negative
error value.

Check the returned value for this error condition, before passing the
value on to other code, which would hide the negative number in some high
value in the unsigned type.

Fixes: 36528c7681b8 ("arm_mpam: resctrl: Add support for 'MB' resource")
Signed-off-by: Andre Przywara <andre.przywara@xxxxxxx>
---
  drivers/resctrl/mpam_resctrl.c | 5 ++++-
  1 file changed, 4 insertions(+), 1 deletion(-)


Reviewed-by: Gavin Shan <gshan@xxxxxxxxxx>

diff --git a/drivers/resctrl/mpam_resctrl.c b/drivers/resctrl/ mpam_resctrl.c
index 9d223057953ab..a5e661eff86d7 100644
--- a/drivers/resctrl/mpam_resctrl.c
+++ b/drivers/resctrl/mpam_resctrl.c
@@ -786,7 +786,10 @@ static u32 get_mba_min(struct mpam_props *cprops)
  /* Find the L3 cache that has affinity with this CPU */
  static int find_l3_equivalent_bitmask(int cpu, cpumask_var_t tmp_cpumask)
  {
-    u32 cache_id = get_cpu_cacheinfo_id(cpu, 3);
+    int cache_id = get_cpu_cacheinfo_id(cpu, 3);
+
+    if (cache_id < 0)
+        return -ENOENT;
      lockdep_assert_cpus_held();

find_l3_equivalent_bitmask() passes @cache_id to find_l3_equivalent_bitmask() as
a 'unsigned long' argument. Actually, it can be 'u32'. It's not directly related
to this patch though.

int mpam_get_cpumask_from_cache_id(unsigned long cache_id, ...);

can be:

int mpam_get_cpumask_from_cache_id(u32 cache_id, ...);


Hi Gavin,

Thanks for pointing this out. I've made exactly this change in my MPAM
DT series (v2, in preparation) — mpam_get_cpumask_from_cache_id() is
changed from unsigned long to u32 there, along with the related cache-id
variables.
https://lore.kernel.org/all/20260811-mpam-resctrl-dt-knp-support-v1-6-ea6397bead59@xxxxxxxxxxxxxxxx/

I'm about to post v2 of that series and will make sure you're on Cc, in
case you'd like to take a look.


Thanks for head-up, please keep me on the cc list. I would like to review
if I get bandwidth, but no promise :)

I noticed RFCv1 series of DT support for MPAM was posted to linux-kernel@xxxxxxxxxxxxxxx
instead of linux-arm-kernel@xxxxxxxxxxxxxxxxxxx. Since MPAM is a arm64 feature, it's
reasonable to post the patches to linux-arm-kernel@xxxxxxxxxxxxxxxxxxx at the same time.

MAINTAINERS doesn't indicates a maillist for MPAM patches in section "MPAM DRIVER". I guess it
would be something worthy to be added.

Thanks,
Gavin