Re: [PATCH net v11] can: isotp: fix timer drain order, wakeup handling and tx_gen ordering
Oliver Hartkopp <[email protected]> Sun, 26 Jul 2026 09:06:58 +0200
| Newsgroups | org.kernel.vger.linux-can,org.kernel.vger.netdev |
|---|---|
| Message-ID | <[email protected]> |
On 25.07.26 14:31, [email protected] wrote: >> + >> + /* drain to avoid stale error for a later poll()/SO_ERROR */ >> + sock_error(sk); >> + >> + return err ? err : size; > > [Severity: High] > Does discarding the return value of sock_error() here silently drop > asynchronous RX socket errors? > > If a concurrent RX timeout or malformed PDU sets sk->sk_err to ETIMEDOUT > or EBADMSG, calling sock_error(sk) will unconditionally clear it to 0. Since > the returned value is ignored and the function prioritizes returning the TX > result or size, it seems the application will never be notified of these RX > failures via sendmsg(), poll(), or getsockopt(SO_ERROR). > > Should we preserve or return this error if no TX error occurred? sk_err is a single per-socket slot shared by the RX and TX paths, so it cannot cleanly separate a TX result from a concurrent RX error. Note that a plain unreliable datagram protocol like UDP/IP gives no feedback for bad or missing received data at all - it just silently drops it. ISO-TP does a bit more and surfaces RX problems (EBADMSG/EILSEQ/ETIMEDOUT) via sk_err on a best-effort basis, which is fine: for an unreliable protocol these are ultimately caught by timeouts at a higher ISO layer anyway. What this patch fixes to 100% is the send path's POSIX contract: sendmsg() now returns the TX-specific result from tx_result[] (>0 bytes on success, <0 on a real TX error), instead of returning whatever happened to sit in sk_err - which could misreport an unrelated concurrent RX error as the TX outcome. Draining sk_err afterwards is required in CAN_ISOTP_WAIT_TX_DONE mode, since the result is delivered synchronously via the return value. So the send path is now correct and race-free; the shared-sk_err RX notification stays best-effort by design. Truly separating the two would need distinct RX/TX error channels (e.g. MSG_ERRQUEUE), which is a feature, not a fix, and out of scope here. Best regards, Oliver