| Message ID | 20221031143317.938785-1-biju.das.jz@bp.renesas.com (mailing list archive) |
|---|---|
| State | Awaiting Upstream |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | can: rcar_canfd: rcar_canfd_handle_global_receive(): fix IRQ storm on global FIFO receive | expand |
| Context | Check | Description |
|---|---|---|
| netdev/tree_selection | success | Series ignored based on subject |
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.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. 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
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,
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.com 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(-)