Re: [PATCH 2/2] can: j1939: check received packet count before completing session

[Liu Chao <liuc63@xiaopeng.com>]

Addressed in v2:
https://lore.kernel.org/all/20260909173105.158202-1-liuc63@xiaopeng.com/

> Does this inadvertently suppress the diagnostic warning for EOMA size
> mismatches on transmitter sessions?

Yes.  v2 emits the warning for both rx and tx and gates only the abort on
!session->transmission.

> Could this error path cause a permanent leak of the session structure
> and permanently block the SA/DA address pair?

v2 returns early for sessions already in J1939_SESSION_WAITING_ABORT, so
the deactivation timer armed by the earlier abort keeps running.  Same
failure mode as 1809c82aa073 ("net: can: j1939:
j1939_xtp_rx_rts_session_active(): deactivate session upon receiving the
second rts").  j1939_session_cancel() is fragile here in general -- the
cts_one and dat_one cancel paths are still unguarded -- but that is a
separate patch.

> This is a pre-existing issue, but looking at j1939_session_cancel()
> exposed by this path, could it trigger an AB-BA deadlock?

Pre-existing, and this series adds no new locking: j1939_xtp_rx_eoma_one()
calls j1939_session_cancel() from the same RX softirq context as the
existing cts_one and dat_one cancel paths, so the reachability of the
cycle is unchanged.  Fixing it means restructuring how
j1939_session_cancel() cancels the rxtimer under active_session_list_lock;
that is a separate change.