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

[Ben Horgan]

Hi Andre,

On 16/09/2026 14:34, Andre Przywara wrote:
> Hi,
> 
> On 9/16/26 11:49, Ben Horgan wrote:
>> Hi Andre,
>>
>> On 07/09/2026 13:59, Ben Horgan wrote:
>>> Hi Andre,
>>>
>>> On 02/09/2026 15:37, 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>
>>>
>>> This looks good to me. Out of interest what led you to find this?
>>>
>>> Reviewed-by: Ben Horgan <ben.horgan@xxxxxxx>
>>
>> I seem to have been a bit hasty here.
>>
>> Sashiko points out at [1] that 0xFFFFFFFF is the only value we were previously considering invalid
>> and that the value coming from dt or acpi can provid other valid values that would after this patch
>> be considered invalid.
> 
> Fair, and I can easily change the check to only check explicitly for -1.
> 
> But this is somewhat broken already, right? I mean the return type for the existing
> get_cpu_cacheinfo_id() has always been "int". It looks like this comes from the x86 world, where the
> cache IDs never get that large? I can have a deeper look, but my gut feeling is that this is

The cache_id being in the PPTT table is a fairly new addition introduced for PPTT table version 3
and introduced to drivers/acpi/pptt.c as part of the preparations for the MPAM driver at the end of
2025. At this point, it seems I neglected to consider any potential effect on
get_cpu_cacheinfo_id(). The pptt cacheid takes any u32 value apart from 0. I haven't joined all the
dots but I expect there might be some tidying up needed in this area.

> practically irrelevant, since we barely see Aff3 at all, not to mention high values of it.

Does Aff3 effect the cache id on acpi systems?

Thanks,

Ben>
> Cheers,
> Andre
> 
>>
>> [1] https://sashiko.dev/#/patchset/20260902143757.3469690-1-andre.przywara%40arm.com
>>
>> Thanks,
>>
>> Ben>
>>> Thanks,
>>>
>>> Ben
>>>
>>>> ---
>>>>   drivers/resctrl/mpam_resctrl.c | 5 ++++-
>>>>   1 file changed, 4 insertions(+), 1 deletion(-)
>>>>
>>>> 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();
>>>>   
>>>
>>>
>>
>