Re: [PATCH net 08/20] can: ctucanfd: use self-test mode for PRESUME_ACK

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] NAPI poll loop permanently deadlocks on SKB allocation failure because it returns less than `quota` without calling `napi_complete_done()`.
--

--- Patch [8]: [PATCH net 08/20] can: ctucanfd: use self-test mode for PRESUME_ACK ---
commit 2ad480a34ed756c09679dabe564744f0df8a351d
Author: Avi Weiss <thnkslprpt@gmail.com>

can: ctucanfd: use self-test mode for PRESUME_ACK

Use self-test mode for CAN_CTRLMODE_PRESUME_ACK so transmitted
frames can complete without receiving an ACK.

ACK forbidden mode prevents the controller from acknowledging
received frames and does not implement the presume-ack behavior.

Link: https://patch.msgid.link/20260722192726.230729-1-thnkslprpt@gmail.com

> diff --git a/drivers/net/can/ctucanfd/ctucanfd_base.c b/drivers/net/can/ctucanfd/ctucanfd_base.c
> index 10ebcc13ea656..07d4aa43c700a 100644
> --- a/drivers/net/can/ctucanfd/ctucanfd_base.c
> +++ b/drivers/net/can/ctucanfd/ctucanfd_base.c
> @@ -340,8 +340,8 @@ static void ctucan_set_mode(struct ctucan_priv *priv, const struct can_ctrlmode
>  			(mode_reg & ~REG_MODE_FDE);
>  
>  	mode_reg = (mode->flags & CAN_CTRLMODE_PRESUME_ACK) ?
> -			(mode_reg | REG_MODE_ACF) :
> -			(mode_reg & ~REG_MODE_ACF);
> +			(mode_reg | REG_MODE_STM) :
> +			(mode_reg & ~REG_MODE_STM);
>  
>  	mode_reg = (mode->flags & CAN_CTRLMODE_FD_NON_ISO) ?
>  			(mode_reg | REG_MODE_NISOFD) :

[Severity: High]
This is a pre-existing issue, but I noticed a potential napi deadlock in
ctucan_rx_poll() when reviewing this file.

If skb allocation fails due to memory pressure, ctucan_rx() returns 0:

drivers/net/can/ctucanfd/ctucanfd_base.c:ctucan_rx_poll() {
	while (framecnt && work_done < quota && res > 0) {
		res = ctucan_rx(ndev);
		work_done++;
		framecnt = FIELD_GET(REG_RX_STATUS_RXFRC, ctucan_read32(priv, CTUCANFD_RX_STATUS));
	}
[ ... ]
	if (!framecnt && res != 0) {
		if (napi_complete_done(napi, work_done)) {
[ ... ]

When res is 0, the loop breaks early and work_done is less than quota. However,
because res is 0, the check if (!framecnt && res != 0) evaluates to false,
which prevents napi_complete_done() from being called.

Does this leave the napi instance in the scheduled state without being
on the core's poll list, permanently deadlocking the receive path until the
interface is restarted?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260729102802.505168-1-mkl@pengutronix.de?part=8