Re: [PATCH 1/3] can: ctucanfd: enable NAPI before starting the controller

[Pavel Pisa <pisa@fel.cvut.cz>]

Hello Patrick Zhang,

thanks for the problem finding and patch.

On Wednesday 21 of October 2026 22:59:22 Patrick Zhang wrote:
> ctucan_open() starts the controller and unmasks RBNEI in
> ctucan_chip_start(), prints "ctu_can_fd device registered", and only
> then calls napi_enable(). A frame that arrives in that window raises
> RBNEI. ctucan_interrupt() masks RBNEI and calls napi_schedule(). NAPI is
> still disabled, so napi_schedule_prep() finds NAPI_STATE_SCHED set and
> the schedule is dropped. napi_enable() then clears SCHED without
> scheduling anything. Only ctucan_rx_poll() unmasks RBNEI again, and it
> never runs. The interface receives nothing until the next close.
> Transmit still works. The RX FIFO fills up and the core sets DOR, but
> the overrun is only accounted in ctucan_rx_poll(), so rx_errors and
> rx_over_errors stay at zero and nothing is logged. Every re-open (ip
> link down/up, a driver rebind) runs the same race again.
>
> The netdev_info() in the window makes it much wider on a slow console.
> This can be reproduced by sending continuous traffic with cangen from
> another node and repeating "ip link set down/up" on the test device.
>
> Enable NAPI before the controller starts, so that an early RX interrupt
> can schedule the poll. NAPI can be enabled while the controller is in
> reset, because nothing schedules it until an interrupt arrives. If
> ctucan_chip_start() fails, disable NAPI again. Otherwise the next open
> would call napi_enable() on an already enabled instance and trip the
> BUG_ON() in napi_enable_locked().
>
> Tested on QEMU with the ctucan_pci device.
>
> Fixes: 2dcb8e8782d8 ("can: ctucanfd: add support for CTU CAN FD open-source
> IP core - bus independent part.") Cc: stable@vger.kernel.org
> Assisted-by: LLM
> Signed-off-by: Patrick Zhang <patrzhan@amazon.com>

Acked-by: Pavel Pisa <pisa@fel.cvut.cz>
Tested-by: Pavel Pisa <pisa@fel.cvut.cz>

I have added patch into our CAN latency testing system

https://canbus.pages.fel.cvut.cz/#can-bus-channels-mutual-latency-testing
https://canbus.pages.fel.cvut.cz/can-latester/

See in the log for both master 7.3.0-gcac8667a979c
and RT tested branch 7.1.1-rt2-g1661cb7f80a0

-> Running pre-build script /var/lib/latester/patches-dut/apply-script.sh
Applying: can: ctucanfd: enable NAPI before starting the controller
-> Setting up build dir

I have spotted problem appearing in out-of-the-tree device tree overlay
driver build which is consequence of CAN unrelated this night change
in mainline which required next fix

--- a/dtbocfg.c
+++ b/dtbocfg.c
@@ -263,7 +263,11 @@ static struct configfs_attribute *dtbocfg_overlay_attrs[] = {
     NULL,
 };

-static struct configfs_bin_attribute *dtbocfg_overlay_bin_attrs[] = {
+static
+#if (LINUX_VERSION_CODE >= KERNEL_VERSION(7, 3, 0))
+const
+#endif
+struct configfs_bin_attribute *dtbocfg_overlay_bin_attrs[] = {
     &dtbocfg_overlay_item_attr_dtbo,
     NULL,
 };

As for fully-preemptive kernel testing, we have been on the git

https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git/refs/heads

at the branch for-kbuild-bot/current-stable but that seems to be no longer
active to track latest RT development above stable branch so it is
time to switch to some else branch or master. Ideal would be something
above next with lattest RT fixes applied before they reach mainline.
But we probably switch to mainline with RT config if nothing better
to catch possible RT deviations (changes in latency or some bugs)
is suggested.

For the curiosity, we have run CTU CAN FD IP core on 64-core
RISC-V with 7.3 kernel and drivers to control motor servosystem
based on ESP32C5 over CAN FD on the SUSE booth at Open Source
Summit for most of the days and it performed well

  https://social.kernel.org/notice/BBBNKOIUZ3NnMKcsXQ

Best wishes,

                Pavel

                Pavel Pisa
    phone:      +420 603531357
    e-mail:     pisa@cmp.felk.cvut.cz
    Department of Control Engineering FEE CVUT
    Karlovo namesti 13, 121 35, Prague 2
    university: http://control.fel.cvut.cz/
    personal:   http://cmp.felk.cvut.cz/~pisa
    social:     https://social.kernel.org/ppisa
    projects:   https://www.openhub.net/accounts/ppisa
    CAN related:http://canbus.pages.fel.cvut.cz/
    RISC-V education: https://comparch.edu.cvut.cz/
    Open Technologies Research Education and Exchange Services
    https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home