netdev - RE: [PATCH 1/3] can: rcar_canfd: Fix IRQ storm on global fifo receive

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 for Android: free password hash cracker in your pocket

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

Date:   Mon, 24 Oct 2022 16:55:56 +0000
From:   Biju Das <biju.das.jz@...renesas.com>
To:     Marc Kleine-Budde <mkl@...gutronix.de>
CC:     Wolfgang Grandegger <wg@...ndegger.com>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Vincent Mailhol <mailhol.vincent@...adoo.fr>,
        Stefan Mätje <stefan.maetje@....eu>,
        Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@...renesas.com>,
        Ulrich Hecht <uli+renesas@...nd.eu>,
        Christophe JAILLET <christophe.jaillet@...adoo.fr>,
        Rob Herring <robh@...nel.org>,
        "linux-can@...r.kernel.org" <linux-can@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        Chris Paterson <Chris.Paterson2@...esas.com>,
        "linux-renesas-soc@...r.kernel.org" 
        <linux-renesas-soc@...r.kernel.org>
Subject: RE: [PATCH 1/3] can: rcar_canfd: Fix IRQ storm on global fifo receive

Hi Marc,
> Subject: Re: [PATCH 1/3] can: rcar_canfd: Fix IRQ storm on global fifo
> receive
> 
> On 24.10.2022 17:37:35, Marc Kleine-Budde wrote:
> > On 22.10.2022 09:15:01, Biju Das wrote:
> > > We are seeing IRQ storm on global receive IRQ line under heavy CAN
> > > bus load conditions with both CAN channels are enabled.
> > >
> > > Conditions:
> > >   The global receive IRQ line is shared between can0 and can1,
> either
> > >   of the channels can trigger interrupt while the other channel
> irq
> > >   line is disabled(rfie).
> > >   When global receive IRQ interrupt occurs, we mask the interrupt
> in
> > >   irqhandler. Clearing and unmasking of the interrupt is happening
> in
> > >   rx_poll(). There is a race condition where rx_poll unmask the
> > >   interrupt, but the next irq handler does not mask the irq due to
> > >   NAPIF_STATE_MISSED flag.
> >
> > Why does this happen? Is it a problem that you call
> > rcar_canfd_handle_global_receive() for a channel that has the IRQs
> > actually disabled in hardware?
> 
> Can you check if the IRQ is active _and_ enabled before handling the
> IRQ on a particular channel?

You mean IRQ handler or rx_poll()??

IRQ handler check the status and disable(mask) the IRQ line.
rx_poll() clears the status and enable(unmask) the IRQ line.

Status flag is set by HW while line is in disabled/enabled state.

Channel0 and channel1 has 2 IRQ lines within the IP which is ored together
to provide global receive interrupt(shared line).


> 
> A more clearer approach would be to get rid of the global interrupt
> handlers at all. If the hardware only given 1 IRQ line for more than 1
> channel, the driver would register an IRQ handler for each channel
> (with the shared attribute). The IRQ handler must check, if the IRQ is
> pending and enabled. If not return IRQ_NONE, otherwise handle and
> return IRQ_HANDLED.

That involves restructuring the IRQ handler altogether.

RZ/G2L has shared line for rx fifos {ch0 and ch1} -> 2 IRQ routine with shared attributes
R-Car SoCs has shared line for rx fifos {ch0 and ch1} and error interrupts->3 IRQ routines with shared attributes.
R-CarV3U SoCs has shared line for rx fifos {ch0 to ch8} and error interrupts->9 IRQ routines with shared attributes.

Yes, I can send follow up patches for migrating to shared interrupt handlers as enhancement.
Please let me know.

Cheers,
Biju