| 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
| ||
|
Message-ID: <7423272c-9efb-403b-8473-b4a46ccf5ff0@amd.com>
Date: Tue, 19 Nov 2024 10:15:51 -0600
From: Mario Limonciello <mario.limonciello@....com>
To: Armin Wolf <W_Armin@....de>, Hans de Goede <hdegoede@...hat.com>,
Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
Cc: "Rafael J . Wysocki" <rafael@...nel.org>, Len Brown <lenb@...nel.org>,
Maximilian Luz <luzmaximilian@...il.com>, Lee Chun-Yi <jlee@...e.com>,
Shyam Sundar S K <Shyam-sundar.S-k@....com>,
Corentin Chary <corentin.chary@...il.com>, "Luke D . Jones"
<luke@...nes.dev>, Ike Panhc <ike.pan@...onical.com>,
Henrique de Moraes Holschuh <hmh@....eng.br>,
Alexis Belmonte <alexbelm48@...il.com>,
Uwe Kleine-König <u.kleine-koenig@...gutronix.de>,
Ai Chao <aichao@...inos.cn>, Gergo Koteles <soyer@....hu>,
open list <linux-kernel@...r.kernel.org>,
"open list:ACPI" <linux-acpi@...r.kernel.org>,
"open list:MICROSOFT SURFACE PLATFORM PROFILE DRIVER"
<platform-driver-x86@...r.kernel.org>,
"open list:THINKPAD ACPI EXTRAS DRIVER"
<ibm-acpi-devel@...ts.sourceforge.net>,
Mark Pearson <mpearson-lenovo@...ebb.ca>,
Matthew Schwartz <matthew.schwartz@...ux.dev>
Subject: Re: [PATCH v6 11/22] ACPI: platform_profile: Add name attribute to
class interface
On 11/19/2024 06:26, Armin Wolf wrote:
> Am 19.11.24 um 05:09 schrieb Mario Limonciello:
>
>> On 11/18/2024 18:28, Armin Wolf wrote:
>>> Am 18.11.24 um 20:43 schrieb Armin Wolf:
>>>
>>>> Am 09.11.24 um 05:41 schrieb Mario Limonciello:
>>>>
>>>>> The name attribute shows the name of the associated platform profile
>>>>> handler.
>>>>>
>>>>> Tested-by: Mark Pearson <mpearson-lenovo@...ebb.ca>
>>>>> Signed-off-by: Mario Limonciello <mario.limonciello@....com>
>>>>> ---
>>>>> drivers/acpi/platform_profile.c | 27 +++++++++++++++++++++++++++
>>>>> 1 file changed, 27 insertions(+)
>>>>>
>>>>> diff --git a/drivers/acpi/platform_profile.c
>>>>> b/drivers/acpi/platform_profile.c
>>>>> index ef6af2c655524..4e2eda18f7f5f 100644
>>>>> --- a/drivers/acpi/platform_profile.c
>>>>> +++ b/drivers/acpi/platform_profile.c
>>>>> @@ -25,8 +25,35 @@ static_assert(ARRAY_SIZE(profile_names) ==
>>>>> PLATFORM_PROFILE_LAST);
>>>>>
>>>>> static DEFINE_IDA(platform_profile_ida);
>>>>>
>>>>> +/**
>>>>> + * name_show - Show the name of the profile handler
>>>>> + * @dev: The device
>>>>> + * @attr: The attribute
>>>>> + * @buf: The buffer to write to
>>>>> + * Return: The number of bytes written
>>>>> + */
>>>>> +static ssize_t name_show(struct device *dev,
>>>>> + struct device_attribute *attr,
>>>>> + char *buf)
>>>>> +{
>>>>> + struct platform_profile_handler *handler = dev_get_drvdata(dev);
>>>>> +
>>>>> + scoped_cond_guard(mutex_intr, return -ERESTARTSYS,
>>>>> &profile_lock) {
>>>>> + return sysfs_emit(buf, "%s\n", handler->name);
>>>>> + }
>>>>> + return -ERESTARTSYS;
>>>>
>>>> I still have a bad feeling about the locking inside the class
>>>> attributes...
>>>>
>>>> Can we assume that no sysfs accesses occur after unregistering the
>>>> class device?
>>>>
>>>> Even if this is not the case then the locking fails to protect the
>>>> platform_profile_handler here.
>>>> If the device is unregistered right after dev_get_drvdata() was
>>>> called, then we would sill operate
>>>> on possibly stale data once we take the profile_lock.
>>>>
>>>> Does someone have any clue how sysfs attributes act during removal?
>>>>
>>> I think i found the answer to my questions inside this patch series:
>>> https://lore.kernel.org/linux-kernel/1390951311-15325-1-git-send-email-
>>> tj@...nel.org
>>>
>>> It says that:
>>>
>>> kernfs / sysfs implement the "sever" semantic for userland
>>> accesses.
>>> When a node is removed, no further userland operations are
>>> allowed and
>>> the in-flight ones are drained before removal is finished. This
>>> makes
>>> policing post-mortem userland accesses trivial for its users.
>>>
>>> In this case taking the profile_lock when reading/writing class
>>> attributes seems to be unnecessary.
>>> Please remove the unnecessary locking inside the class attributes.
>>>
>>
>> Before I respin a v7, let's make sure we're agreed on which things
>> need locking and which don't.
>>
>> Functions that check if a lock is held:
>> _store_class_profile()
>> _notify_class_profile()
>> get_class_profile()
>> _aggregate_choices()
>>
>> Functions that take a lock:
>> name_show()
>> choices_show()
>> profile_show()
>> profile_store()
>> platform_profile_choices_show()
>> platform_profile_show()
>> platform_profile_store()
>> platform_profile_cycle()
>> platform_profile_register()
>> platform_profile_remove()
>>
>> Functions that don't take or check for a lock (these are intermediary
>> and things they call check for one):
>> _aggregate_profiles()
>> _store_and_notify()
>>
>> Are you suggesting that basically these 4 can drop taking the lock?
>> name_show()
>> choices_show()
>> profile_show()
>> profile_store()
>>
>> I think the show() ones I can get behind, but I'm worried about
>> profile_store(), particularly as it pertains to the other callers of
>> _store_class_profile() because it's incongruent how the other callers
>> would use it then.
>>
>> Can we perhaps just drop it for the 3 class attribute show() ones?
>
> I think so, i also remembered that profile_store() needs to keep taking
> the lock in case platform_profile_cycle() is currently
> running.
Actually considering this, we need to keep it on profile_show() too then
for the exact same reason.
I will drop it for choices and name though.
>
> Can you also remove the second call to dev_get_drvdata() in
> _store_class_profile()?
>
Sure.
> Thanks,
> Armin Wolf
>
>>
>> LMK.
>>
>>
>>
Powered by blists - more mailing lists