[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0175d3ce84ea0aa938a3ce9b3731762e@kernel.org>
Date: Wed, 07 Oct 2020 13:09:33 +0100
From: Marc Zyngier <maz@...nel.org>
To: Andy Shevchenko <andy.shevchenko@...il.com>
Cc: Linus Walleij <linus.walleij@...aro.org>,
"open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
linux-kernel@...r.kernel.org,
Bartosz Golaszewski <bgolaszewski@...libre.com>,
kernel-team@...roid.com
Subject: Re: [PATCH] gpio: pca953x: Survive spurious interrupts
On 2020-10-07 13:02, Andy Shevchenko wrote:
> On Wed, Oct 7, 2020 at 12:49 PM Linus Walleij
> <linus.walleij@...aro.org> wrote:
>>
>> On Mon, Oct 5, 2020 at 4:02 PM Marc Zyngier <maz@...nel.org> wrote:
>>
>> > The pca953x driver never checks the result of irq_find_mapping(),
>> > which returns 0 when no mapping is found. When a spurious interrupt
>> > is delivered (which can happen under obscure circumstances), the
>> > kernel explodes as it still tries to handle the error code as
>> > a real interrupt.
>> >
>> > Handle this particular case and warn on spurious interrupts.
>> >
>> > Signed-off-by: Marc Zyngier <maz@...nel.org>
>
> Wait, doesn't actually [1] fix the reported issue?
Not at all.
> Marc, can you confirm this?
>
> [1]: e43c26e12dd4 ("gpio: pca953x: Fix uninitialized pending variable")
Different bug, really. If an interrupt is *really* pending, and no
mapping established yet, feeding the result of irq_find_mapping() to
handle_nested_irq() will lead to a panic.
Recently seen on a Tegra system suffering from even more pathological
bugs.
M.
--
Jazz is not dead. It just smells funny...
Powered by blists - more mailing lists