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

Yin Li yin.li at oss.qualcomm.com
Sun Sep 13 23:45:42 PDT 2026



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 at arm.com>
>>>> ---
>>>>   drivers/resctrl/mpam_resctrl.c | 5 ++++-
>>>>   1 file changed, 4 insertions(+), 1 deletion(-)
>>>>
>>>
>>> Reviewed-by: Gavin Shan <gshan at redhat.com>
>>>
>>>> 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 at oss.qualcomm.com/
>>
>> 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 at vger.kernel.org
> instead of linux-arm-kernel at lists.infradead.org. Since MPAM is a arm64 
> feature, it's
> reasonable to post the patches to linux-arm-kernel at lists.infradead.org 
> at the same time.
> 

Good point on linux-arm-kernel — I'll make sure v2 goes to
linux-arm-kernel at lists.infradead.org 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




More information about the linux-arm-kernel mailing list