| Message ID | 20230916-upstream-net-20230915-mptcp-hanging-conn-v1-0-05d1a8b851a8@tessares.net (mailing list archive) |
|---|---|
| Headers | show |
| Series | mptcp: fix stalled connections | expand |
Hello: This series was applied to netdev/net.git (main) by David S. Miller <davem@davemloft.net>: On Sat, 16 Sep 2023 12:52:44 +0200 you wrote: > Daire reported a few issues with MPTCP where some connections were > stalled in different states. Paolo did a great job fixing them. > > Patch 1 fixes bogus receive window shrinkage with multiple subflows. Due > to a race condition and unlucky circumstances, that may lead to > TCP-level window shrinkage, and the connection being stalled on the > sender end. > > [...] Here is the summary with links: - [net,1/5] mptcp: fix bogus receive window shrinkage with multiple subflows https://git.kernel.org/netdev/net/c/6bec041147a2 - [net,2/5] mptcp: move __mptcp_error_report in protocol.c https://git.kernel.org/netdev/net/c/d5fbeff1ab81 - [net,3/5] mptcp: process pending subflow error on close https://git.kernel.org/netdev/net/c/9f1a98813b4b - [net,4/5] mptcp: rename timer related helper to less confusing names https://git.kernel.org/netdev/net/c/f6909dc1c1f4 - [net,5/5] mptcp: fix dangling connection hang-up https://git.kernel.org/netdev/net/c/27e5ccc2d5a5 You are awesome, thank you!
Daire reported a few issues with MPTCP where some connections were stalled in different states. Paolo did a great job fixing them. Patch 1 fixes bogus receive window shrinkage with multiple subflows. Due to a race condition and unlucky circumstances, that may lead to TCP-level window shrinkage, and the connection being stalled on the sender end. Patch 2 is a preparation for patch 3 which processes pending subflow errors on close. Without that and under specific circumstances, the MPTCP-level socket might not switch to the CLOSE state and stall. Patch 4 is also a preparation patch for the next one. Patch 5 fixes MPTCP connections not switching to the CLOSE state when all subflows have been closed but no DATA_FIN have been exchanged to explicitly close the MPTCP connection. Now connections in such state will switch to the CLOSE state after a timeout, still allowing the "make-after-break" feature but making sure connections don't stall forever. It will be possible to modify this timeout -- currently matching TCP TIMEWAIT value (60 seconds) -- in a future version. Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net> --- Paolo Abeni (5): mptcp: fix bogus receive window shrinkage with multiple subflows mptcp: move __mptcp_error_report in protocol.c mptcp: process pending subflow error on close mptcp: rename timer related helper to less confusing names mptcp: fix dangling connection hang-up net/mptcp/options.c | 5 +- net/mptcp/protocol.c | 165 +++++++++++++++++++++++++++++++-------------------- net/mptcp/protocol.h | 24 +++++++- net/mptcp/subflow.c | 39 +----------- 4 files changed, 130 insertions(+), 103 deletions(-) --- base-commit: 615efed8b63f60ddd69c0b8f32f7783859034fc2 change-id: 20230915-upstream-net-20230915-mptcp-hanging-conn-0609338b1728 Best regards,