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

[Mario Limonciello <mario.limonciello@amd.com>]

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?

LMK.