Re: [PATCH] reset: gpio: suppress bind attributes in sysfs

[Krzysztof Kozlowski <krzk@kernel.org>]

On 04/12/2025 12:22, Bartosz Golaszewski wrote:
> On Thu, Dec 4, 2025 at 12:14 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>
>> On 04/12/2025 10:44, Bartosz Golaszewski wrote:
>>> This is a special device that's created dynamically and is supposed to
>>> stay in memory forever. We also currently don't have a devlink between
>>
>> Not forever. If every consumer is unloaded, this can be unloaded too, no?
>>
>>> it and the actual reset consumer. Suppress sysfs bind attributes so that
>>
>> With that reasoning every reset consumer should have suppress binds.
>> Devlink should be created by reset controller framework so it is not
>> this driver's fault.
>>
> 
> Here's my reasoning: I will add a devlink but Phillipp requested some
> changes so I still need to resend it. It will be a bigger change than
> this one-liner. The reset-gpio device was also converted to auxiliary
> bus for v6.19 and I will also convert reset core to using fwnodes for
> v6.20 so we'll significantly diverge in stable branches, while this
> issue is present ever since the reset-gpio driver exists. It's not the
> driver's fault but it's easier to fix it here and it very much is a
> special case - it's a software based device rammed in between two
> firmware-described devices.

That's not the answer to my question. You can unbind every other reset
controller. Why is this special although maybe you mentioned below?

> 
>>
>>> user-space can't unbind the device because - as of now - it will cause a
>>> use-after-free splat from any user that puts the reset control handle.
>>>
>>> Fixes: cee544a40e44 ("reset: gpio: Add GPIO-based reset controller")
>>
>> Nothing to be fixed here, unless you claim that every reset provider is
>> broken as well? What is exactly different in handling devlinks between
>> this driver and every other reset provider?
>>
> 
> I don't care if we keep the tag, it's just that this commit introduced
> a way for user-space to crash the system by simply unbinding
> reset-gpio and then its active consumers.
> 
> And the difference here is that there is no devlink between reset-gpio
> and its consumers. We need to first agree how to add it.

So you mean that between every other reset consumer and reset provider
there is a devlink? And here there is no devlink?


Best regards,
Krzysztof