[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAOprWosSvBmORh9NKk-uxoWZpD6zdnF=dODS-uxVnTDjmofL6g@mail.gmail.com>
Date: Thu, 18 Sep 2025 20:58:33 +0800
From: Andrea Daoud <andreadaoud6@...il.com>
To: Marc Kleine-Budde <mkl@...gutronix.de>
Cc: Heiko Stuebner <heiko@...ech.de>, Elaine Zhang <zhangqing@...k-chips.com>, kernel@...gutronix.de,
linux-can@...r.kernel.org, netdev@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-rockchip@...ts.infradead.org,
linux-kernel@...r.kernel.org
Subject: Possible race condition of the rockchip_canfd driver
Hi Marc,
I'm using the rockchip_canfd driver on an RK3568. When under high bus
load, I get
the following logs [1] in rkcanfd_tx_tail_is_eff, and the CAN bus is unable to
communicate properly under this condition. The exact cause is currently not
entirely clear, and it's not reliably reproducible.
In the logs we can spot some strange points:
1. Line 24, tx_head == tx_tail. This should have been rejected by the if
(!rkcanfd_get_tx_pending) clause.
2. Line 26, the last bit of priv->tx_tail (0x0185dbb3) is 1. This means that the
tx_tail should be 1, because rkcanfd_get_tx_tail is essentially mod the
priv->tx_tail by two. But the printed tx_tail is 0.
I believe these problems could mean that the code is suffering from some race
condition. It seems that, in the whole IRQ processing chain of the driver,
there's no lock protection. Maybe some IRQ happens within the execution of
rkcanfd_tx_tail_is_eff, and touches the state of the tx_head and tx_tail?
Could you please have a look at the code, and check if some locking is needed?
[1]: https://pastebin.com/R7uuEKEz
Powered by blists - more mailing lists