linux-kernel - Re: [PATCH v5 15/34] arm_mpam: Add helpers for managing the locking around the mon

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <d13bb673-a033-4020-a984-19b4ab560be9@arm.com>
Date: Wed, 19 Nov 2025 10:12:25 +0000
From: Ben Horgan <ben.horgan@....com>
To: Fenghua Yu <fenghuay@...dia.com>, james.morse@....com
Cc: amitsinght@...vell.com, baisheng.gao@...soc.com,
 baolin.wang@...ux.alibaba.com, bobo.shaobowang@...wei.com,
 carl@...amperecomputing.com, catalin.marinas@....com, dakr@...nel.org,
 dave.martin@....com, david@...hat.com, dfustini@...libre.com,
 gregkh@...uxfoundation.org, gshan@...hat.com, guohanjun@...wei.com,
 jeremy.linton@....com, jonathan.cameron@...wei.com, kobak@...dia.com,
 lcherian@...vell.com, lenb@...nel.org, linux-acpi@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
 lpieralisi@...nel.org, peternewman@...gle.com, quic_jiles@...cinc.com,
 rafael@...nel.org, robh@...nel.org, rohit.mathew@....com,
 scott@...amperecomputing.com, sdonthineni@...dia.com, sudeep.holla@....com,
 tan.shaopeng@...itsu.com, will@...nel.org, xhao@...ux.alibaba.com,
 Shaopeng Tan <tan.shaopeng@...fujitsu.com>, Zeng Heng <zengheng4@...wei.com>
Subject: Re: [PATCH v5 15/34] arm_mpam: Add helpers for managing the locking
 around the mon_sel registers

Hi Fenghua,

On 11/19/25 04:13, Fenghua Yu wrote:
> Hi, Ben,
> 
> On 11/17/25 08:59, Ben Horgan wrote:
>> From: James Morse <james.morse@....com>
>>
>> The MSC MON_SEL register needs to be accessed from hardirq for the
>> overflow
>> interrupt, and when taking an IPI to access these registers on platforms
>> where MSC are not accessible from every CPU. This makes an irqsave
>> spinlock the obvious lock to protect these registers. On systems with
>> SCMI
>> or PCC mailboxes it must be able to sleep, meaning a mutex must be used.
>> The SCMI or PCC platforms can't support an overflow interrupt, and
>> can't access the registers from hardirq context.
>>
>> Clearly these two can't exist for one MSC at the same time.
>>
>> Add helpers for the MON_SEL locking. For now, use a irqsave spinlock and
>> only support 'real' MMIO platforms.
>>
>> In the future this lock will be split in two allowing SCMI/PCC platforms
>> to take a mutex. Because there are contexts where the SCMI/PCC platforms
>> can't make an access, mpam_mon_sel_lock() needs to be able to fail. Do
>> this now, so that all the error handling on these paths is present. This
>> allows the relevant paths to fail if they are needed on a platform where
>> this isn't possible, instead of having to make explicit checks of the
>> interface type.
>>
>> Reviewed-by: Jonathan Cameron <jonathan.cameron@...wei.com>
>> Reviewed-by: Gavin Shan <gshan@...hat.com>
>> Reviewed-by: Shaopeng Tan <tan.shaopeng@...fujitsu.com>
>> Reviewed-by: Fenghua Yu <fenghuay@...dia.com>
>> Tested-by: Fenghua Yu <fenghuay@...dia.com>
>> Tested-by: Shaopeng Tan <tan.shaopeng@...fujitsu.com>
>> Tested-by: Peter Newman <peternewman@...gle.com>
>> Tested-by: Carl Worth <carl@...amperecomputing.com>
>> Tested-by: Gavin Shan <gshan@...hat.com>
>> Tested-by: Zeng Heng <zengheng4@...wei.com>
>> Signed-off-by: James Morse <james.morse@....com>
>> Signed-off-by: Ben Horgan <ben.horgan@....com
> 
> [SNIP]
> 
>> diff --git a/drivers/resctrl/mpam_internal.h b/drivers/resctrl/
>> mpam_internal.h
>> index 768a58a3ab27..b62ee55e1ed5 100644
>> --- a/drivers/resctrl/mpam_internal.h
>> +++ b/drivers/resctrl/mpam_internal.h
> 
> [SNIP]
> 
>> +/* Returning false here means accesses to mon_sel must fail and
>> report an error. */
>> +static inline bool __must_check mpam_mon_sel_lock(struct mpam_msc *msc)
>> +{
>> +    WARN_ON_ONCE(msc->iface != MPAM_IFACE_MMIO);
>> +
>> +    raw_spin_lock_irqsave(&msc->_mon_sel_lock, msc->_mon_sel_flags);
>> +    return true;
>> +}
> 
> This helper always returns true, never false. And this may cause issue
> later.
> 
> On the bottom line, this causes confusion in the comment and when later
> its return value is always checked by callers.
> 
> It's better to improve this helper?
> 
> Option 1: warn and return false when ris->iface is not MMIO. No changes
> in other patches which call the helper. Seems this is a better fix.

Ok. The return value checking is intentional so that the locking for the
firmware backed interface can be easily re-instated to the driver later.
I'll return false when ris->iface is not MMIO but we won't get there as
the probe will have already failed.

> Option 2: warn on non MMIO iface but no return value. Other patches need
> to be changed when calling the helper.
> 
> Thanks.
> 
> -Fenghua

-- 
Thanks,

Ben