linux-kernel - Re: [RFC PATCH 17/36] arm_mpam: Add cpuhp callbacks to probe MSC hardware

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <2164fca1-0a78-4c72-b93b-2b95d5f41e08@arm.com>
Date: Wed, 6 Aug 2025 19:07:25 +0100
From: James Morse <james.morse@....com>
To: Baisheng Gao <baisheng.gao@...soc.com>
Cc: amitsinght@...vell.com, baolin.wang@...ux.alibaba.com,
 ben.horgan@....com, bobo.shaobowang@...wei.com, carl@...amperecomputing.com,
 dave.martin@....com, david@...hat.com, dfustini@...libre.com,
 kobak@...dia.com, lcherian@...vell.com, lecopzerc@...dia.com,
 linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
 peternewman@...gle.com, quic_jiles@...cinc.com, rex.nie@...uarmicro.com,
 robh@...nel.org, rohit.mathew@....com, scott@...amperecomputing.com,
 sdonthineni@...dia.com, shameerali.kolothum.thodi@...wei.com,
 tan.shaopeng@...itsu.com, xhao@...ux.alibaba.com, zengheng4@...wei.com,
 hao_hao.wang@...soc.com
Subject: Re: [RFC PATCH 17/36] arm_mpam: Add cpuhp callbacks to probe MSC
 hardware

Hi Baisheng,

On 29/07/2025 07:11, Baisheng Gao wrote:
>> Because an MSC can only by accessed from the CPUs in its cpu-affinity
>> set we need to be running on one of those CPUs to probe the MSC
>> hardware.
>>
>> Do this work in the cpuhp callback. Probing the hardware will only
>> happen before MPAM is enabled, walk all the MSCs and probe those we can
>> reach that haven't already been probed.
>>
>> Later once MPAM is enabled, this cpuhp callback will be replaced by
>> one that avoids the global list.
>>
>> Enabling a static key will also take the cpuhp lock, so can't be done
>> from the cpuhp callback. Whenever a new MSC has been probed schedule
>> work to test if all the MSCs have now been probed.


>> diff --git a/drivers/platform/arm64/mpam/mpam_devices.c b/drivers/platform/arm64/mpam/mpam_devices.c
>> index 0d6d5180903b..89434ae3efa6 100644
>> --- a/drivers/platform/arm64/mpam/mpam_devices.c
>> +++ b/drivers/platform/arm64/mpam/mpam_devices.c
>> @@ -513,9 +541,84 @@ int mpam_ris_create(struct mpam_msc *msc, u8 ris_idx,
>> +static void mpam_register_cpuhp_callbacks(int (*online)(unsigned int online),
>> +					  int (*offline)(unsigned int offline))
>> +{
>> +	mutex_lock(&mpam_cpuhp_state_lock);
>> +	if (mpam_cpuhp_state) {
>> +		cpuhp_remove_state(mpam_cpuhp_state);
>> +		mpam_cpuhp_state = 0;
>> +	}
>> +
>> +	mpam_cpuhp_state = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "mpam:online",
>> +					     online, offline);
>> +	if (mpam_cpuhp_state <= 0) {
>> +		pr_err("Failed to register cpuhp callbacks");
>> +		mpam_cpuhp_state = 0;
>> +	}
>> +	mutex_unlock(&mpam_cpuhp_state_lock);
>>  }
>>  
>>  static int mpam_dt_count_msc(void)

>> @@ -797,6 +900,46 @@ static struct platform_driver mpam_msc_driver = {
>> +static void mpam_enable_once(void)
>> +{
>> +	mutex_lock(&mpam_cpuhp_state_lock);
>> +	cpuhp_remove_state(mpam_cpuhp_state);
>> +	mpam_cpuhp_state = 0;
>> +	mutex_unlock(&mpam_cpuhp_state_lock);

> Deleting the above 4 lines?
> The mpam_cpuhp_state will be removed firstly in mpam_register_cpuhp_callbacks
> if the mpam_cpuhp_state isn't 0.

Yup - this is a pointless appendage because of the way the code evolved!
Thanks for catching it


James

>> +
>> +	mpam_register_cpuhp_callbacks(mpam_cpu_online, mpam_cpu_offline);
>> +
>> +	pr_info("MPAM enabled\n");
>> +}