Re: [PATCH mptcp-net v3] mptcp: fix divide-by-zero in __mptcp_push_pending close path
Paolo Abeni <[email protected]> Wed, 22 Jul 2026 10:53:50 +0200
| Newsgroups | dev.linux.lists.mptcp |
|---|---|
| Message-ID | <[email protected]> |
On 6/12/26 8:33 PM, Shardul Bankar wrote: > Gentle ping on v3. It refines the v2 check that tripped the > regressions, scoping it to just the divide-by-zero close-path case. CI > on v3 was green except for a single Unstable flag (packetdrill_dss on > the debug config) a flaky test unrelated to this change (it passed on > normal). > > Does v3 look acceptable as-is, or is there anything else you'd like > adjusted? I'm sorry for the latency. netdev PW backlog is killing me. I fear this patch may introduce another race: if a ssk with !__tcp_can_send() status reaches mptcp_sendmsg_frag(), `mss_now` could be zero and we can hit a divide by zero in tcp_xmit_size_goal(). I think syzkaller hit such race in the past. Re-reading the patch changelog it's not clear to me the exact timing of the race this patch should address: if __mptcp_close_ssk() leaves ssk in a !__tcp_can_send() status, mptcp_subflow_get_send() should not pick such subflow for transmission, as the latter explicitly gates subflow selection with the same condition[1]. Is the repro using a BPF scheduler? Can you describe exactly the sequence of events leading to the error? The decoded call trace will help, but will not suffice in case of another process racing on the relevant ssk - I think it's the latter case, due to [1]. I still think that refining the approach in v2 would be better. Did you trace why self-tests were failing? I can't find a reply in that old thread. Thanks, Paolo