[PATCH] arm_mpam: Fix MPAM reset on resctrl unmount by clearing in_reset_state

[PATCH] arm_mpam: Fix MPAM reset on resctrl unmount by clearing in_reset_state

[Zeng Heng]

When resctrl is unmounted, MPAM components should be reset to default
configurations to avoid impacting system performance. However, after
a user updates MPAM configuration via mpam_apply_config(), the
in_reset_state flag remains true, causing mpam_reset_ris() to skip
the actual register restoration on subsequent resets.

For example, after mounting resctrl and modifying the root group's
schemata (e.g., changing MBMAX/MBMIN values), unmounting resctrl
would leave the modified MPAM settings in hardware registers since
mpam_reset_ris() returns early due to in_reset_state still being true.
This results in persistent performance restrictions even after resctrl
is umounted.

Fix by clearing in_reset_state to false immediately after successful
configuration application, ensuring that the next reset operation
properly restores MPAM register defaults.

Fixes: f188a36ca241 ("arm_mpam: Reset MSC controls from cpuhp callbacks")
Signed-off-by: Zeng Heng <zengheng4@huawei.com>
---
The in_reset_state state machine has been carefully reviewed, particularly
the handling in mpam_cpu_online() where the flag is checked before
applying configurations. in_reset_state indicates whether the RIS is
currently using default configurations. This change aligns with the
original design intent and does not introduce semantic breakage to
existing state transitions.
---
 drivers/resctrl/mpam_devices.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/resctrl/mpam_devices.c b/drivers/resctrl/mpam_devices.c
index 460ea98a1c92..044227ee033f 100644
--- a/drivers/resctrl/mpam_devices.c
+++ b/drivers/resctrl/mpam_devices.c
@@ -2932,6 +2932,7 @@ int mpam_apply_config(struct mpam_component *comp, u16 partid,
 					 srcu_read_lock_held(&mpam_srcu)) {
 			arg.ris = ris;
 			mpam_touch_msc(msc, __write_config, &arg);
+			ris->in_reset_state = false;
 		}
 		mutex_unlock(&msc->cfg_lock);
 	}
--
2.25.1

Re: [PATCH] arm_mpam: Fix MPAM reset on resctrl unmount by clearing in_reset_state

[Ben Horgan]

Hi Zeng,

On 2/13/26 07:50, Zeng Heng wrote:
> When resctrl is unmounted, MPAM components should be reset to default
> configurations to avoid impacting system performance. However, after
> a user updates MPAM configuration via mpam_apply_config(), the
> in_reset_state flag remains true, causing mpam_reset_ris() to skip
> the actual register restoration on subsequent resets.
> 
> For example, after mounting resctrl and modifying the root group's
> schemata (e.g., changing MBMAX/MBMIN values), unmounting resctrl

nit: MBMIN isn't currently supported in resctrl. I'd just drop the
part in brackets.

> would leave the modified MPAM settings in hardware registers since
> mpam_reset_ris() returns early due to in_reset_state still being true.
> This results in persistent performance restrictions even after resctrl
> is umounted.
> 
> Fix by clearing in_reset_state to false immediately after successful
> configuration application, ensuring that the next reset operation
> properly restores MPAM register defaults.
> 
> Fixes: f188a36ca241 ("arm_mpam: Reset MSC controls from cpuhp callbacks")

mpam_apply_config() doesn't exist in this commit. I would have expected:
Fixes: 09b89d2a72f3 ("arm_mpam: Allow configuration to be applied and restored during cpu online")

> Signed-off-by: Zeng Heng <zengheng4@huawei.com>

The change and justification looks good to me.

Acked-by: Ben Horgan <ben.horgan@arm.com>

Thanks,

Ben

> ---
> The in_reset_state state machine has been carefully reviewed, particularly
> the handling in mpam_cpu_online() where the flag is checked before
> applying configurations. in_reset_state indicates whether the RIS is
> currently using default configurations. This change aligns with the
> original design intent and does not introduce semantic breakage to
> existing state transitions.
> ---
>  drivers/resctrl/mpam_devices.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/resctrl/mpam_devices.c b/drivers/resctrl/mpam_devices.c
> index 460ea98a1c92..044227ee033f 100644
> --- a/drivers/resctrl/mpam_devices.c
> +++ b/drivers/resctrl/mpam_devices.c
> @@ -2932,6 +2932,7 @@ int mpam_apply_config(struct mpam_component *comp, u16 partid,
>  					 srcu_read_lock_held(&mpam_srcu)) {
>  			arg.ris = ris;
>  			mpam_touch_msc(msc, __write_config, &arg);
> +			ris->in_reset_state = false;
>  		}
>  		mutex_unlock(&msc->cfg_lock);
>  	}
> --
> 2.25.1
> 

Re: [PATCH] arm_mpam: Fix MPAM reset on resctrl unmount by clearing in_reset_state

[Ben Horgan]

On 2/17/26 15:59, Ben Horgan wrote:
> Hi Zeng,
> 
> On 2/13/26 07:50, Zeng Heng wrote:
>> When resctrl is unmounted, MPAM components should be reset to default
>> configurations to avoid impacting system performance. However, after
>> a user updates MPAM configuration via mpam_apply_config(), the
>> in_reset_state flag remains true, causing mpam_reset_ris() to skip
>> the actual register restoration on subsequent resets.
>>
>> For example, after mounting resctrl and modifying the root group's
>> schemata (e.g., changing MBMAX/MBMIN values), unmounting resctrl
> 
> nit: MBMIN isn't currently supported in resctrl. I'd just drop the
> part in brackets.
> 
>> would leave the modified MPAM settings in hardware registers since
>> mpam_reset_ris() returns early due to in_reset_state still being true.
>> This results in persistent performance restrictions even after resctrl
>> is umounted.
>>
>> Fix by clearing in_reset_state to false immediately after successful
>> configuration application, ensuring that the next reset operation
>> properly restores MPAM register defaults.
>>
>> Fixes: f188a36ca241 ("arm_mpam: Reset MSC controls from cpuhp callbacks")
> 
> mpam_apply_config() doesn't exist in this commit. I would have expected:
> Fixes: 09b89d2a72f3 ("arm_mpam: Allow configuration to be applied and restored during cpu online")
> 
>> Signed-off-by: Zeng Heng <zengheng4@huawei.com>
> 
> The change and justification looks good to me.
> 
> Acked-by: Ben Horgan <ben.horgan@arm.com>
> 

I'll add this on to the start of the current mpam resctrl series as even
though this is squashing an existing bug it can't be hit until mpam has
a user interface and so doesn't need to go as a fix.

Thanks,

Ben

Re: [PATCH] arm_mpam: Fix MPAM reset on resctrl unmount by clearing in_reset_state

[Zeng Heng]

Hi Ben,

On 2026/2/27 22:16, Ben Horgan wrote:
> 
> 
> On 2/17/26 15:59, Ben Horgan wrote:
>> Hi Zeng,
>>
>> On 2/13/26 07:50, Zeng Heng wrote:
>>> When resctrl is unmounted, MPAM components should be reset to default
>>> configurations to avoid impacting system performance. However, after
>>> a user updates MPAM configuration via mpam_apply_config(), the
>>> in_reset_state flag remains true, causing mpam_reset_ris() to skip
>>> the actual register restoration on subsequent resets.
>>>
>>> For example, after mounting resctrl and modifying the root group's
>>> schemata (e.g., changing MBMAX/MBMIN values), unmounting resctrl
>>
>> nit: MBMIN isn't currently supported in resctrl. I'd just drop the
>> part in brackets.
>>
>>> would leave the modified MPAM settings in hardware registers since
>>> mpam_reset_ris() returns early due to in_reset_state still being true.
>>> This results in persistent performance restrictions even after resctrl
>>> is umounted.
>>>
>>> Fix by clearing in_reset_state to false immediately after successful
>>> configuration application, ensuring that the next reset operation
>>> properly restores MPAM register defaults.
>>>
>>> Fixes: f188a36ca241 ("arm_mpam: Reset MSC controls from cpuhp callbacks")
>>
>> mpam_apply_config() doesn't exist in this commit. I would have expected:
>> Fixes: 09b89d2a72f3 ("arm_mpam: Allow configuration to be applied and restored during cpu online")
>>
>>> Signed-off-by: Zeng Heng <zengheng4@huawei.com>
>>
>> The change and justification looks good to me.
>>
>> Acked-by: Ben Horgan <ben.horgan@arm.com>
>>
> 
> I'll add this on to the start of the current mpam resctrl series as even
> though this is squashing an existing bug it can't be hit until mpam has
> a user interface and so doesn't need to go as a fix.
> 
> Thanks,
> 
> Ben
> 
> 
OK, get it.

Best regards,
Zeng Heng