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

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 bec=
ause it returns less than `quota` without calling `napi_complete_done()`.
--

--- Patch [8]: [PATCH net 08/20] can: ctucanfd: use self-test mode for PRES=
UME_ACK ---
commit 2ad480a34ed756c09679dabe564744f0df8a351d
Author: Avi Weiss <[email protected]>

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/[email protected]

> diff --git a/drivers/net/can/ctucanfd/ctucanfd_base.c b/drivers/net/can/c=
tucanfd/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);
> =20
>  	mode_reg =3D (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);
> =20
>  	mode_reg =3D (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 =3D ctucan_rx(ndev);
		work_done++;
		framecnt =3D FIELD_GET(REG_RX_STATUS_RXFRC, ctucan_read32(priv, CTUCANFD_=
RX_STATUS));
	}
[ ... ]
	if (!framecnt && res !=3D 0) {
		if (napi_complete_done(napi, work_done)) {
[ ... ]

When res is 0, the loop breaks early and work_done is less than quota. Howe=
ver,
because res is 0, the check if (!framecnt && res !=3D 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?

--=20
Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260729102802.5051=
[email protected]?part=3D8