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: <c28f04f8-3989-45d4-b630-2cc35574e47a@arm.com>
Date: Fri, 17 Oct 2025 19:51:19 +0100
From: James Morse <james.morse@....com>
To: Markus Elfring <Markus.Elfring@....de>, linux-acpi@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org
Cc: LKML <linux-kernel@...r.kernel.org>,
 Amit Singh Tomar <amitsinght@...vell.com>,
 Baisheng Gao <baisheng.gao@...soc.com>,
 Baolin Wang <baolin.wang@...ux.alibaba.com>, Ben Horgan
 <ben.horgan@....com>, Carl Worth <carl@...amperecomputing.com>,
 Catalin Marinas <catalin.marinas@....com>,
 D Scott Phillips <scott@...amperecomputing.com>,
 Danilo Krummrich <dakr@...nel.org>, Dave Martin <Dave.Martin@....com>,
 David Hildenbrand <david@...hat.com>, Drew Fustini <dfustini@...libre.com>,
 Fenghua Yu <fenghuay@...dia.com>,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Hanjun Guo <guohanjun@...wei.com>, Jamie Iles <quic_jiles@...cinc.com>,
 Jonathan Cameron <Jonathan.Cameron@...wei.com>, Koba Ko <kobak@...dia.com>,
 Len Brown <lenb@...nel.org>, Linu Cherian <lcherian@...vell.com>,
 Lorenzo Pieralisi <lpieralisi@...nel.org>,
 Peter Newman <peternewman@...gle.com>, "Rafael J. Wysocki"
 <rafael@...nel.org>, Rob Herring <robh@...nel.org>,
 Rohit Mathew <rohit.mathew@....com>,
 Shanker Donthineni <sdonthineni@...dia.com>,
 Sudeep Holla <sudeep.holla@....com>, Shaopeng Tan
 <tan.shaopeng@...itsu.com>, Wang ShaoBo <bobo.shaobowang@...wei.com>,
 Will Deacon <will@...nel.org>, Xin Hao <xhao@...ux.alibaba.com>
Subject: Re: [PATCH v2 08/29] arm_mpam: Add the class and component structures
 for firmware described ris

Hi Markus,

On 26/09/2025 19:15, Markus Elfring wrote:
>>> …
>>>> +++ b/drivers/resctrl/mpam_devices.c
>>> …
>>>>> +int mpam_ris_create(struct mpam_msc *msc, u8 ris_idx,
>>>> +		    enum mpam_class_types type, u8 class_id, int component_id)
>>>> +{
>>>> +	int err;
>>>> +
>>>> +	mutex_lock(&mpam_list_lock);
>>>> +	err = mpam_ris_create_locked(msc, ris_idx, type, class_id,
>>>> +				     component_id);
>>>> +	mutex_unlock(&mpam_list_lock);
>>> …
>>>
>>> Under which circumstances would you become interested to apply a statement
>>> like “guard(mutex)(&mpam_list_lock);”?
>>> https://elixir.bootlin.com/linux/v6.17-rc5/source/include/linux/mutex.h#L228
>>
>> None! The bit of this you cut out is a call to mpam_free_garbage() which calls
>> synchronize_srcu(). That may sleep for a while. The whole point of the deferred free-ing
>> is it does not happen under the lock. The 'guard' magic means the compiler gets to choose
>> when to call unlock.
> 
> How does this feedback fit to the proposed addition of a mutex_lock()/mutex_unlock()
> call combination (which might be achievable also with another programming interface)?

Right - I've muddled the horde of "must use guard srcu" with the horde of "must use guard
mutex". In this case I'd still prefer we don't spuriously hold the write side lock when
doing the deferred free-ing.


Thanks,

James

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ