summaryrefslogtreecommitdiff
path: root/tools/lib/python
diff options
context:
space:
mode:
authorPaolo Abeni <pabeni@redhat.com>2025-11-21 20:02:10 +0300
committerJakub Kicinski <kuba@kernel.org>2025-11-25 06:49:42 +0300
commit0eeb372deebce6c25b9afc09e35d6c75a744299a (patch)
tree805dffcd98cb483d63d892b2784a15293788c0c5 /tools/lib/python
parent38a4a469c850fc007d6fe2429b1f7f492e50e7ad (diff)
downloadlinux-0eeb372deebce6c25b9afc09e35d6c75a744299a.tar.xz
mptcp: handle first subflow closing consistently
Currently, as soon as the PM closes a subflow, the msk stops accepting data from it, even if the TCP socket could be still formally open in the incoming direction, with the notable exception of the first subflow. The root cause of such behavior is that code currently piggy back two separate semantic on the subflow->disposable bit: the subflow context must be released and that the subflow must stop accepting incoming data. The first subflow is never disposed, so it also never stop accepting incoming data. Use a separate bit to mark the latter status and set such bit in __mptcp_close_ssk() for all subflows. Beyond making per subflow behaviour more consistent this will also simplify the next patch. Signed-off-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Mat Martineau <martineau@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20251121-net-next-mptcp-memcg-backlog-imp-v1-11-1f34b6c1e0b1@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Diffstat (limited to 'tools/lib/python')
0 files changed, 0 insertions, 0 deletions