[PATCH] can: rcar_canfd: rcar_canfd_handle_global_receive(): fix IRQ storm on global FIFO receive
commit 702de2c21eed04c67cefaaedc248ef16e5f6b293 upstream.
We are seeing an IRQ storm on the global receive IRQ line under heavy CAN bus load conditions with both CAN channels enabled.
Conditions:
The global receive IRQ line is shared between can0 and can1, either of the channels can trigger interrupt while the other channel's IRQ line is disabled (RFIE).
When global a receive IRQ interrupt occurs, we mask the interrupt in the IRQ handler. Clearing and unmasking of the interrupt is happening in rx_poll(). There is a race condition where rx_poll() unmasks the interrupt, but the next IRQ handler does not mask the IRQ due to NAPIF_STATE_MISSED flag (e.g.: can0 RX FIFO interrupt is disabled and can1 is triggering RX interrupt, the delay in rx_poll() processing results in setting NAPIF_STATE_MISSED flag) leading to an IRQ storm.
This patch fixes the issue by checking IRQ active and enabled before handling the IRQ on a particular channel.
Fixes: dd3bd23eb438 ("can: rcar_canfd: Add Renesas R-Car CAN FD driver") Suggested-by: Marc Kleine-Budde mkl@pengutronix.de Signed-off-by: Biju Das biju.das.jz@bp.renesas.com Link: https://lore.kernel.org/all/20221025155657.1426948-2-biju.das.jz@bp.renesas.... Cc: stable@vger.kernel.org#5.15.y [mkl: adjust commit message] Signed-off-by: Marc Kleine-Budde mkl@pengutronix.de [biju: removed gpriv from RCANFD_RFCC_RFIE macro] Signed-off-by: Biju Das biju.das.jz@bp.renesas.com --- Resending to 5.15 with confilcts[1] fixed [1] https://lore.kernel.org/stable/1667194204110137@kroah.com/T/#u --- drivers/net/can/rcar/rcar_canfd.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/can/rcar/rcar_canfd.c b/drivers/net/can/rcar/rcar_canfd.c index 2f44c567ebd7..9991bb475ae1 100644 --- a/drivers/net/can/rcar/rcar_canfd.c +++ b/drivers/net/can/rcar/rcar_canfd.c @@ -1106,11 +1106,13 @@ static void rcar_canfd_handle_global_receive(struct rcar_canfd_global *gpriv, u3 { struct rcar_canfd_channel *priv = gpriv->ch[ch]; u32 ridx = ch + RCANFD_RFFIFO_IDX; - u32 sts; + u32 sts, cc;
/* Handle Rx interrupts */ sts = rcar_canfd_read(priv->base, RCANFD_RFSTS(ridx)); - if (likely(sts & RCANFD_RFSTS_RFIF)) { + cc = rcar_canfd_read(priv->base, RCANFD_RFCC(ridx)); + if (likely(sts & RCANFD_RFSTS_RFIF && + cc & RCANFD_RFCC_RFIE)) { if (napi_schedule_prep(&priv->napi)) { /* Disable Rx FIFO interrupts */ rcar_canfd_clear_bit(priv->base,
Hi!
Fixes: dd3bd23eb438 ("can: rcar_canfd: Add Renesas R-Car CAN FD driver") Suggested-by: Marc Kleine-Budde mkl@pengutronix.de Signed-off-by: Biju Das biju.das.jz@bp.renesas.com Link: https://lore.kernel.org/all/20221025155657.1426948-2-biju.das.jz@bp.renesas.... Cc: stable@vger.kernel.org#5.15.y [mkl: adjust commit message]
I got 7 or so copies of this, with slightly different Cc: lines.
AFAICT this is supposed to be stable kernel submission. In such case, I'd expect [PATCH 4.14, 4.19, 5.10] in the subject line, and original sign-off block from the mainline patch.
OTOH if it has Fixes tag (and it does) or Cc: stable (it has both), normally there's no need to do separate submission to stable, as Greg handles these automatically?
Thanks and best regards, Pavel
Hi Pavel,
Thanks for the feedback.
Subject: Re: [PATCH] can: rcar_canfd: rcar_canfd_handle_global_receive(): fix IRQ storm on global FIFO receive
Hi!
Fixes: dd3bd23eb438 ("can: rcar_canfd: Add Renesas R-Car CAN FD driver") Suggested-by: Marc Kleine-Budde mkl@pengutronix.de Signed-off-by: Biju Das biju.das.jz@bp.renesas.com Link: https://lore.kernel.org/all/20221025155657.1426948-2-
biju.das.jz@bp.re
nesas.com Cc: stable@vger.kernel.org#5.15.y [mkl: adjust commit message]
I got 7 or so copies of this, with slightly different Cc: lines.
I followed option 1 mentioned in [1]
[1] https://www.kernel.org/doc/html/v5.10/process/stable-kernel-rules.html
AFAICT this is supposed to be stable kernel submission. In such case, I'd expect [PATCH 4.14, 4.19, 5.10] in the subject line, and original sign-off block from the mainline patch.
OK. Maybe [1] needs updating.
OTOH if it has Fixes tag (and it does) or Cc: stable (it has both), normally there's no need to do separate submission to stable, as Greg handles these automatically?
I got merge conflict mails for 4.9, 4.14, 4.19, 5.4, 5.10 and 5.15 stable. I thought, I need to fix the conflicts and resend. Am I missing anything?? Please let me know.
Cheers, biju
On 11/1/22 14:59, Biju Das wrote:
I got 7 or so copies of this, with slightly different Cc: lines.
I followed option 1 mentioned in [1]
[1] https://www.kernel.org/doc/html/v5.10/process/stable-kernel-rules.html
AFAICT this is supposed to be stable kernel submission. In such case, I'd expect [PATCH 4.14, 4.19, 5.10] in the subject line, and original sign-off block from the mainline patch.
OK. Maybe [1] needs updating.
The documentation says (in this case the third option applies):
Send the patch, after verifying that it follows the above rules, to> stable@vger.kernel.org. You must note the upstream commit ID in the changelog of your submission, as well as the kernel version you wish it to be applied to.
It doesn't specify how to mark desired target branch, unfortunately.
OTOH if it has Fixes tag (and it does) or Cc: stable (it has both), normally there's no need to do separate submission to stable, as Greg handles these automatically?
I got merge conflict mails for 4.9, 4.14, 4.19, 5.4, 5.10 and 5.15 stable. I thought, I need to fix the conflicts and resend. Am I missing anything?? Please let me know.
The upstream commit didn't apply cleanly to *all* stable branches due to conflicts, right?
Thanks.
On Tue, Nov 01, 2022 at 07:36:20PM +0700, Bagas Sanjaya wrote:
On 11/1/22 14:59, Biju Das wrote:
I got 7 or so copies of this, with slightly different Cc: lines.
I followed option 1 mentioned in [1]
[1] https://www.kernel.org/doc/html/v5.10/process/stable-kernel-rules.html
AFAICT this is supposed to be stable kernel submission. In such case, I'd expect [PATCH 4.14, 4.19, 5.10] in the subject line, and original sign-off block from the mainline patch.
OK. Maybe [1] needs updating.
The documentation says (in this case the third option applies):
Send the patch, after verifying that it follows the above rules, to> stable@vger.kernel.org. You must note the upstream commit ID in the changelog of your submission, as well as the kernel version you wish it to be applied to.
It doesn't specify how to mark desired target branch, unfortunately.
And that's fine, the submitter did the right thing here and gave me all of the information that I need. Please do not confuse people, there is nothing wrong with the submission as-is.
thanks,
greg k-h
linux-stable-mirror@lists.linaro.org
-
Bagas Sanjaya -
Biju Das -
gregkh＠linuxfoundation.org -
Pavel Machek