diff options
| author | Paolo Abeni <pabeni@redhat.com> | 2025-11-21 20:02:10 +0300 |
|---|---|---|
| committer | Jakub Kicinski <kuba@kernel.org> | 2025-11-25 06:49:42 +0300 |
| commit | 0eeb372deebce6c25b9afc09e35d6c75a744299a (patch) | |
| tree | 805dffcd98cb483d63d892b2784a15293788c0c5 /tools/lib/python | |
| parent | 38a4a469c850fc007d6fe2429b1f7f492e50e7ad (diff) | |
| download | linux-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
