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

[Ben Horgan]

Hi James,

On 02/10/2026 16:01, James Morse wrote:
> 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...

Yeah, fine for now. We'll have to think more when we fix the unbinding.

Thanks,

Ben

> 
> 
>>  		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@xxxxxxx>
> 
> 
> Thanks,
> 
> James