Re: [PATCH v2 04/12] arm_mpam: Add missing mon_sel locking in MBWU save and restore

[James Morse <james.morse@arm.com>]

Hi Ben,

On 17/09/2026 15:56, Ben Horgan wrote:
> The mon_sel_lock is used to protect the mbwu_state, as well as h/w accesses
> that use MPAMCFG_MON_SEL. However, in mpam_restore/save_mbwu_state(),
> mbwu_state is accessed without holding the mon_sel_lock.

This is me being sloppy - I was only worried about concurrent writers, not
use of the array itself. But this is clearly better!


> Add the missing locking.


> diff --git a/drivers/resctrl/mpam_devices.c b/drivers/resctrl/mpam_devices.c
> index e349db525882..d39d210574a6 100644
> --- a/drivers/resctrl/mpam_devices.c
> +++ b/drivers/resctrl/mpam_devices.c
> @@ -1652,17 +1652,26 @@ static int mpam_restore_mbwu_state(void *_ris)
>  	u64 val;
>  	struct mon_read mwbu_arg;
>  	struct mpam_msc_ris *ris = _ris;
> +	struct mpam_msc *msc = ris->vmsc->msc;
>  	struct mpam_class *class = ris->vmsc->comp->class;
>  
>  	for (i = 0; i < ris->props.num_mbwu_mon; i++) {
> -		if (ris->mbwu_state[i].enabled) {
> -			mwbu_arg.ris = ris;
> -			mwbu_arg.ctx = &ris->mbwu_state[i].cfg;
> -			mwbu_arg.type = mpam_msmon_choose_counter(class);
> -			mwbu_arg.val = &val;
> +		if (WARN_ON_ONCE(!mpam_mon_sel_lock(msc)))
> +			return -EIO;
>  
> -			__ris_msmon_read(&mwbu_arg);
> +		if (!ris->mbwu_state[i].enabled) {
> +			mpam_mon_sel_unlock(msc);
> +			continue;
>  		}
> +
> +		mwbu_arg.ris = ris;
> +		mwbu_arg.ctx = &ris->mbwu_state[i].cfg;
> +		mwbu_arg.type = mpam_msmon_choose_counter(class);
> +		mwbu_arg.val = &val;

> +		mpam_mon_sel_unlock(msc);
> +
> +		__ris_msmon_read(&mwbu_arg);

Dropping and re-taking the lock in __ris_msmon_read() means everything we cached
in mbwu_arg could in principle change. I don't think it does - but if we're trying
to be robust/unsurprising: we probably need a __ris_msmon_read_locked(), or because of
that cfg pointer - always get the caller to take the lock.

This is better - so we shouldn't let perfect be the enemy of good.

~

Turns out you clean this up in a few patches time. It's theoretical, so the order
doesn't matter.


>  	}
>  
>  	return 0;
> @@ -1680,12 +1689,12 @@ static int mpam_save_mbwu_state(void *arg)
>  	struct mpam_msc *msc = ris->vmsc->msc;
>  
>  	for (i = 0; i < ris->props.num_mbwu_mon; i++) {
> -		mbwu_state = &ris->mbwu_state[i];
> -		cfg = &mbwu_state->cfg;

Yeah, I was only worried about concurrent writes. But this is clearly better.


>  		if (WARN_ON_ONCE(!mpam_mon_sel_lock(msc)))
>  			return -EIO;
>  
> +		mbwu_state = &ris->mbwu_state[i];
> +		cfg = &mbwu_state->cfg;
To check - do you agree we don't need to worry about the array being free()d?
Because the first thing teardown does is disable the static-key and unregister
the cpuhp callbacks, it shouldn't be possible to reach this code before the
array gets freed...


>  		mon_sel = FIELD_PREP(MSMON_CFG_MON_SEL_MON_SEL, i) |
>  			  FIELD_PREP(MSMON_CFG_MON_SEL_RIS, ris->ris_idx);
>  		mpam_write_monsel_reg(msc, CFG_MON_SEL, mon_sel);


Reviewed-by: James Morse <james.morse@arm.com>


Thanks,

James