Re: [PATCH v6 11/22] ACPI: platform_profile: Add name attribute to class interface

[Armin Wolf <W_Armin@gmx.de>]

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@squebb.ca>
>>>> Signed-off-by: Mario Limonciello <mario.limonciello@amd.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.
>>
>
> 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.

Can you also remove the second call to dev_get_drvdata() in _store_class_profile()?

Thanks,
Armin Wolf

>
> LMK.
>
>
>