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'


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ