[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6b7d2f80-0dde-4f07-b889-fa2cb99f5c88@gmx.de>
Date: Tue, 19 Nov 2024 01:28:08 +0100
From: Armin Wolf <W_Armin@....de>
To: Mario Limonciello <mario.limonciello@....com>,
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
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@kernel.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.
Thanks,
Armin Wolf
> Thanks,
> Armin Wolf
>
>> +}
>> +
>> +static DEVICE_ATTR_RO(name);
>> +static struct attribute *profile_attrs[] = {
>> + &dev_attr_name.attr,
>> + NULL
>> +};
>> +ATTRIBUTE_GROUPS(profile);
>> +
>> static const struct class platform_profile_class = {
>> .name = "platform-profile",
>> + .dev_groups = profile_groups,
>> };
>>
>> static ssize_t platform_profile_choices_show(struct device *dev,
>
Powered by blists - more mailing lists