Hi Ben,
On 29/08/2025 15:30, Ben Horgan wrote:
> On 8/22/25 16:30, James Morse wrote:
>> cpuhp callbacks aren't the only time the MSC configuration may need to
>> be reset. Resctrl has an API call to reset a class.
>> If an MPAM error interrupt arrives it indicates the driver has
>> misprogrammed an MSC. The safest thing to do is reset all the MSCs
>> and disable MPAM.
>>
>> Add a helper to reset RIS via their class. Call this from mpam_disable(),
>> which can be scheduled from the error interrupt handler.
>> diff --git a/drivers/resctrl/mpam_devices.c b/drivers/resctrl/mpam_devices.c
>> index 759244966736..3516cbe8623e 100644
>> --- a/drivers/resctrl/mpam_devices.c
>> +++ b/drivers/resctrl/mpam_devices.c
>> @@ -1569,6 +1567,66 @@ static void mpam_enable_once(void)
>> +/*
>> + * Called in response to an error IRQ.
>> + * All of MPAMs errors indicate a software bug, restore any modified
>> + * controls to their reset values.
>> + */
>> +void mpam_disable(void)
>> +{
>> + int idx;
>> + struct mpam_class *class;
>> +
>> + idx = srcu_read_lock(&mpam_srcu);
>> + list_for_each_entry_srcu(class, &mpam_classes, classes_list,
>> + srcu_read_lock_held(&mpam_srcu))
>
> Why do you use list_for_each_entry_srcu() here when in other places you
> use list_for_each_entry_rcu()?
It's a mistake. I was part way making this use RCU when someone 'invented' the
firmware interface meaning readl() needs to be able to sleep...
Those were added in a later patch than I thought, and I missed fixing them up.
I think the srcu version provides extra checking - and is the correct one to use.
I'll fix those -- thanks for spotting it!
Thanks,
James
>> + mpam_reset_class(class);
>> + srcu_read_unlock(&mpam_srcu, idx);
>> +}
