linux-kernel - Re: [PATCH 2/2] regulator: max20339: add Maxim MAX20339 regulator driver

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <224bfd44-d26a-494c-81ad-560677761d81@kernel.org>
Date: Tue, 17 Sep 2024 10:16:11 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: André Draszik <andre.draszik@...aro.org>,
 Liam Girdwood <lgirdwood@...il.com>, Mark Brown <broonie@...nel.org>,
 Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>, Michael Walle <mwalle@...nel.org>
Cc: Peter Griffin <peter.griffin@...aro.org>,
 Tudor Ambarus <tudor.ambarus@...aro.org>,
 Will McVicker <willmcvicker@...gle.com>, kernel-team@...roid.com,
 linux-kernel@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH 2/2] regulator: max20339: add Maxim MAX20339 regulator
 driver

On 17/09/2024 10:15, Krzysztof Kozlowski wrote:
>>
>>>> +	irq_flags |= irqd_get_trigger_type(irq_get_irq_data(client->irq));
>>>> +
>>>> +	ret = devm_request_threaded_irq(&client->dev, client->irq,
>>>
>>> Shared interrupts should not be devm. It leads to tricky cases during
>>> removal. If you investigated the code and you are 100% sure there is no
>>> issue, please write a short comment in the code confirming that. Or just
>>> don't use devm.
>>
>> I wasn't aware of this, thanks. I'll drop the shared and somebody can
>> revisit it in the future if required. BTW, a naive grep returned +400
>> drivers that use shared together with devm.
> 
> Yeah, I was once thinking to check them, because there is an easy hint
> problems are possible: if driver has remove() callback which does
> anything with resources. However even if driver code looks unsafe, it
> requires quite some time to figure out if the issue is real - need to
> find other driver who will trigger the interrupt afterwards.
> 
> You can BTW test it with CONFIG_DEBUG_SHIRQ + bind/unbind.
> 
> Maybe we need some more explicit documentation around devm() or IRQF_SHARED.

Also discussion here:
https://lore.kernel.org/all/20220929050426.955139-1-dmitry.torokhov@gmail.com/

Best regards,
Krzysztof