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

[Yin Li]

On 9/14/2026 2:35 PM, Gavin Shan wrote:
> 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 :)

Hi Gavin,

Thanks, will keep you on Cc for v2.

> 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.

Good point on linux-arm-kernel — I'll make sure v2 goes to
linux-arm-kernel@xxxxxxxxxxxxxxxxxxx as well.

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

And agreed that the MPAM DRIVER entry in MAINTAINERS is missing an "L:"
mailing list, which is likely why get_maintainer.pl didn't pick up
linux-arm-kernel. I'll note this in the v2 cover letter so the MPAM
maintainers can decide whether to add it.

Thx and BRs,
Yin

> Thanks,
> Gavin

--
Thx and BRs,
Yin