Messages in this thread | | | From | Andy Shevchenko <> | Date | Wed, 7 Oct 2020 16:10:11 +0300 | Subject | Re: [PATCH] gpio: pca953x: Survive spurious interrupts |
| |
On Wed, Oct 7, 2020 at 3:09 PM Marc Zyngier <maz@kernel.org> wrote: > On 2020-10-07 13:02, Andy Shevchenko wrote: > > On Wed, Oct 7, 2020 at 12:49 PM Linus Walleij > > <linus.walleij@linaro.org> wrote: > >> On Mon, Oct 5, 2020 at 4:02 PM Marc Zyngier <maz@kernel.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@kernel.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.
I don't understand. We have plenty of drivers doing exactly the way without checking this returned code. What circumstances makes the mapping be absent?
Shouldn't we rather change this:
girq->handler = handle_simple_irq; to this: girq->handler = handle_bad_irq; ?
> Recently seen on a Tegra system suffering from even more pathological > bugs.
-- With Best Regards, Andy Shevchenko
| |