linux-kernel - Re: [PATCH] pinctrl: samsung: Fix irq handling if an error occurs in exynos_irq_demux_eint16

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: <0cc57d5746de472129b3fa7ba02e1289fab91069.camel@linaro.org>
Date: Tue, 19 Nov 2024 06:35:29 +0000
From: André Draszik <andre.draszik@...aro.org>
To: Christophe JAILLET <christophe.jaillet@...adoo.fr>, Krzysztof Kozlowski
 <krzk@...nel.org>, Sylwester Nawrocki <s.nawrocki@...sung.com>, Alim Akhtar
 <alim.akhtar@...sung.com>, Linus Walleij <linus.walleij@...aro.org>
Cc: linux-kernel@...r.kernel.org, kernel-janitors@...r.kernel.org, Krzysztof
 Kozlowski <krzysztof.kozlowski@...aro.org>,
 linux-arm-kernel@...ts.infradead.org,  linux-samsung-soc@...r.kernel.org,
 linux-gpio@...r.kernel.org
Subject: Re: [PATCH] pinctrl: samsung: Fix irq handling if an error occurs
 in exynos_irq_demux_eint16_31()

Hi Christophe,

On Mon, 2024-11-18 at 21:40 +0100, Christophe JAILLET wrote:
> Also wondering if it is needed in exynos_irq_release_resources() if 
> clk_enable() fails and we early return.
> 
> I don't know how these callbacks are used and if we could dead-lock in 
> such a situation.
> 
> What do you think?

This was pointed out indeed in
https://lore.kernel.org/all/9a960401-f41f-4902-bcbd-8f30f318ba98@kernel.org/
but irq_chip::irq_release_resources() is not expected to fail.

_mask(), _unmask(), and _ack() have a similar issue. In practice, I don't
think the enable has ever failed in our usecase - it's just a simple bit
flip after all.

There are two options, update the callback signatures (and all users...), or
keep the clock on for the whole duration. Given the clock really is needed
for register access only, we didn't do the latter originally:
https://lore.kernel.org/all/0106b6f58ce19752c2c685d128e5a480103ee91c.camel@linaro.org/

Not sure what the preference would be, 2nd option is likely easier to do and
it would be surprising if _mask() etc. suddenly could fail.

Cheers,
Andre'