2020-01-21 16:56:15 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-01-21 16:56:26 -08:00
|
|
|
|
|
|
|
|
|
2025-06-30 09:35:39 +00:00
|
|
|
|
2025-09-02 23:11:36 +02:00
|
|
|
|
2020-01-21 16:56:15 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-07-28 15:12:03 -07:00
|
|
|
|
2020-01-21 16:56:19 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-01-21 16:56:15 -08:00
|
|
|
|
2024-04-29 13:40:21 +00:00
|
|
|
|
2020-11-16 10:48:09 +01:00
|
|
|
|
2021-12-03 14:35:34 -08:00
|
|
|
|
2020-01-21 16:56:15 -08:00
|
|
|
|
2020-03-27 14:48:50 -07:00
|
|
|
|
2020-01-21 16:56:15 -08:00
|
|
|
|
2026-02-03 19:41:20 +01:00
|
|
|
|
|
|
|
|
|
2021-04-16 15:38:04 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-02-06 00:39:37 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-06-03 16:24:32 -07:00
|
|
|
|
|
|
|
|
|
2021-12-03 14:35:32 -08:00
|
|
|
|
2021-06-03 16:24:32 -07:00
|
|
|
|
|
|
|
|
|
2021-11-15 11:02:39 -08:00
|
|
|
|
2020-03-27 14:48:45 -07:00
|
|
|
|
2020-11-16 10:48:09 +01:00
|
|
|
|
2023-06-20 18:24:21 +02:00
|
|
|
|
2020-11-16 10:48:09 +01:00
|
|
|
|
2025-05-12 11:27:33 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-01-12 16:34:55 -08:00
|
|
|
|
2021-01-20 15:39:14 +01:00
|
|
|
|
2020-11-16 10:48:13 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-27 11:10:26 +01:00
|
|
|
|
2020-11-16 10:48:13 +01:00
|
|
|
|
|
|
|
|
|
2023-12-19 22:31:04 +01:00
|
|
|
|
2020-04-02 13:44:51 +02:00
|
|
|
|
mptcp: Fix proto fallback detection with BPF
The sockmap feature allows bpf syscall from userspace, or based
on bpf sockops, replacing the sk_prot of sockets during protocol stack
processing with sockmap's custom read/write interfaces.
'''
tcp_rcv_state_process()
syn_recv_sock()/subflow_syn_recv_sock()
tcp_init_transfer(BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB)
bpf_skops_established <== sockops
bpf_sock_map_update(sk) <== call bpf helper
tcp_bpf_update_proto() <== update sk_prot
'''
When the server has MPTCP enabled but the client sends a TCP SYN
without MPTCP, subflow_syn_recv_sock() performs a fallback on the
subflow, replacing the subflow sk's sk_prot with the native sk_prot.
'''
subflow_syn_recv_sock()
subflow_ulp_fallback()
subflow_drop_ctx()
mptcp_subflow_ops_undo_override()
'''
Then, this subflow can be normally used by sockmap, which replaces the
native sk_prot with sockmap's custom sk_prot. The issue occurs when the
user executes accept::mptcp_stream_accept::mptcp_fallback_tcp_ops().
Here, it uses sk->sk_prot to compare with the native sk_prot, but this
is incorrect when sockmap is used, as we may incorrectly set
sk->sk_socket->ops.
This fix uses the more generic sk_family for the comparison instead.
Additionally, this also prevents a WARNING from occurring:
result from ./scripts/decode_stacktrace.sh:
------------[ cut here ]------------
WARNING: CPU: 0 PID: 337 at net/mptcp/protocol.c:68 mptcp_stream_accept \
(net/mptcp/protocol.c:4005)
Modules linked in:
...
PKRU: 55555554
Call Trace:
<TASK>
do_accept (net/socket.c:1989)
__sys_accept4 (net/socket.c:2028 net/socket.c:2057)
__x64_sys_accept (net/socket.c:2067)
x64_sys_call (arch/x86/entry/syscall_64.c:41)
do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
RIP: 0033:0x7f87ac92b83d
---[ end trace 0000000000000000 ]---
Fixes: 0b4f33def7bb ("mptcp: fix tcp fallback crash")
Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
Reviewed-by: Jakub Sitnicki <jakub@cloudflare.com>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Cc: <stable@vger.kernel.org>
Link: https://patch.msgid.link/20251111060307.194196-3-jiayuan.chen@linux.dev
2025-11-11 14:02:51 +08:00
|
|
|
|
|
|
|
|
|
2020-04-02 13:44:51 +02:00
|
|
|
|
mptcp: Fix proto fallback detection with BPF
The sockmap feature allows bpf syscall from userspace, or based
on bpf sockops, replacing the sk_prot of sockets during protocol stack
processing with sockmap's custom read/write interfaces.
'''
tcp_rcv_state_process()
syn_recv_sock()/subflow_syn_recv_sock()
tcp_init_transfer(BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB)
bpf_skops_established <== sockops
bpf_sock_map_update(sk) <== call bpf helper
tcp_bpf_update_proto() <== update sk_prot
'''
When the server has MPTCP enabled but the client sends a TCP SYN
without MPTCP, subflow_syn_recv_sock() performs a fallback on the
subflow, replacing the subflow sk's sk_prot with the native sk_prot.
'''
subflow_syn_recv_sock()
subflow_ulp_fallback()
subflow_drop_ctx()
mptcp_subflow_ops_undo_override()
'''
Then, this subflow can be normally used by sockmap, which replaces the
native sk_prot with sockmap's custom sk_prot. The issue occurs when the
user executes accept::mptcp_stream_accept::mptcp_fallback_tcp_ops().
Here, it uses sk->sk_prot to compare with the native sk_prot, but this
is incorrect when sockmap is used, as we may incorrectly set
sk->sk_socket->ops.
This fix uses the more generic sk_family for the comparison instead.
Additionally, this also prevents a WARNING from occurring:
result from ./scripts/decode_stacktrace.sh:
------------[ cut here ]------------
WARNING: CPU: 0 PID: 337 at net/mptcp/protocol.c:68 mptcp_stream_accept \
(net/mptcp/protocol.c:4005)
Modules linked in:
...
PKRU: 55555554
Call Trace:
<TASK>
do_accept (net/socket.c:1989)
__sys_accept4 (net/socket.c:2028 net/socket.c:2057)
__x64_sys_accept (net/socket.c:2067)
x64_sys_call (arch/x86/entry/syscall_64.c:41)
do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
RIP: 0033:0x7f87ac92b83d
---[ end trace 0000000000000000 ]---
Fixes: 0b4f33def7bb ("mptcp: fix tcp fallback crash")
Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
Reviewed-by: Jakub Sitnicki <jakub@cloudflare.com>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Cc: <stable@vger.kernel.org>
Link: https://patch.msgid.link/20251111060307.194196-3-jiayuan.chen@linux.dev
2025-11-11 14:02:51 +08:00
|
|
|
|
2023-12-19 22:31:04 +01:00
|
|
|
|
2020-04-02 13:44:51 +02:00
|
|
|
|
mptcp: Fix proto fallback detection with BPF
The sockmap feature allows bpf syscall from userspace, or based
on bpf sockops, replacing the sk_prot of sockets during protocol stack
processing with sockmap's custom read/write interfaces.
'''
tcp_rcv_state_process()
syn_recv_sock()/subflow_syn_recv_sock()
tcp_init_transfer(BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB)
bpf_skops_established <== sockops
bpf_sock_map_update(sk) <== call bpf helper
tcp_bpf_update_proto() <== update sk_prot
'''
When the server has MPTCP enabled but the client sends a TCP SYN
without MPTCP, subflow_syn_recv_sock() performs a fallback on the
subflow, replacing the subflow sk's sk_prot with the native sk_prot.
'''
subflow_syn_recv_sock()
subflow_ulp_fallback()
subflow_drop_ctx()
mptcp_subflow_ops_undo_override()
'''
Then, this subflow can be normally used by sockmap, which replaces the
native sk_prot with sockmap's custom sk_prot. The issue occurs when the
user executes accept::mptcp_stream_accept::mptcp_fallback_tcp_ops().
Here, it uses sk->sk_prot to compare with the native sk_prot, but this
is incorrect when sockmap is used, as we may incorrectly set
sk->sk_socket->ops.
This fix uses the more generic sk_family for the comparison instead.
Additionally, this also prevents a WARNING from occurring:
result from ./scripts/decode_stacktrace.sh:
------------[ cut here ]------------
WARNING: CPU: 0 PID: 337 at net/mptcp/protocol.c:68 mptcp_stream_accept \
(net/mptcp/protocol.c:4005)
Modules linked in:
...
PKRU: 55555554
Call Trace:
<TASK>
do_accept (net/socket.c:1989)
__sys_accept4 (net/socket.c:2028 net/socket.c:2057)
__x64_sys_accept (net/socket.c:2067)
x64_sys_call (arch/x86/entry/syscall_64.c:41)
do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
RIP: 0033:0x7f87ac92b83d
---[ end trace 0000000000000000 ]---
Fixes: 0b4f33def7bb ("mptcp: fix tcp fallback crash")
Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
Reviewed-by: Jakub Sitnicki <jakub@cloudflare.com>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Cc: <stable@vger.kernel.org>
Link: https://patch.msgid.link/20251111060307.194196-3-jiayuan.chen@linux.dev
2025-11-11 14:02:51 +08:00
|
|
|
|
2023-12-19 22:31:04 +01:00
|
|
|
|
2020-04-02 13:44:51 +02:00
|
|
|
|
|
|
|
|
|
2025-07-23 16:32:23 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-11-18 08:20:22 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-07-23 16:32:23 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-09-08 16:07:06 +02:00
|
|
|
|
2025-07-23 16:32:23 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-06-29 22:26:23 +02:00
|
|
|
|
2020-01-21 16:56:17 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-01-12 18:42:51 +01:00
|
|
|
|
2020-01-21 16:56:17 -08:00
|
|
|
|
2020-06-29 22:26:23 +02:00
|
|
|
|
2020-01-21 16:56:17 -08:00
|
|
|
|
2023-07-20 20:47:50 +02:00
|
|
|
|
2023-05-31 12:37:06 -07:00
|
|
|
|
2020-01-21 16:56:17 -08:00
|
|
|
|
2020-01-21 16:56:18 -08:00
|
|
|
|
2020-11-16 10:48:09 +01:00
|
|
|
|
2020-01-21 16:56:17 -08:00
|
|
|
|
2023-06-20 18:30:17 +02:00
|
|
|
|
2022-03-07 12:44:37 -08:00
|
|
|
|
|
|
|
|
|
2024-02-15 19:25:31 +01:00
|
|
|
|
2021-01-20 15:39:10 +01:00
|
|
|
|
2023-08-11 17:57:26 +02:00
|
|
|
|
2020-06-29 22:26:20 +02:00
|
|
|
|
2020-06-29 22:26:23 +02:00
|
|
|
|
2020-01-21 16:56:17 -08:00
|
|
|
|
|
|
|
|
|
2023-04-14 16:08:03 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-08-11 17:57:25 +02:00
|
|
|
|
2023-04-14 16:08:03 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-08-11 17:57:25 +02:00
|
|
|
|
2023-04-14 16:08:03 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-08-11 17:57:25 +02:00
|
|
|
|
2023-04-14 16:08:03 +02:00
|
|
|
|
|
|
|
|
|
2020-09-14 10:01:12 +02:00
|
|
|
|
|
|
|
|
|
2026-08-03 18:16:40 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-08-26 12:50:28 +00:00
|
|
|
|
2020-09-14 10:01:12 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-09-27 11:40:42 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-14 10:01:11 +02:00
|
|
|
|
2025-09-27 11:40:42 +02:00
|
|
|
|
2020-09-14 10:01:11 +02:00
|
|
|
|
2025-02-18 19:36:13 +01:00
|
|
|
|
|
|
|
|
|
2025-09-27 11:40:42 +02:00
|
|
|
|
|
|
|
|
|
2020-09-14 10:01:11 +02:00
|
|
|
|
|
|
|
|
|
mptcp: pr_debug: add missing \n at the end
pr_debug() have been added in various places in MPTCP code to help
developers to debug some situations. With the dynamic debug feature, it
is easy to enable all or some of them, and asks users to reproduce
issues with extra debug.
Many of these pr_debug() don't end with a new line, while no 'pr_cont()'
are used in MPTCP code. So the goal was not to display multiple debug
messages on one line: they were then not missing the '\n' on purpose.
Not having the new line at the end causes these messages to be printed
with a delay, when something else needs to be printed. This issue is not
visible when many messages need to be printed, but it is annoying and
confusing when only specific messages are expected, e.g.
# echo "func mptcp_pm_add_addr_echoed +fmp" \
> /sys/kernel/debug/dynamic_debug/control
# ./mptcp_join.sh "signal address"; \
echo "$(awk '{print $1}' /proc/uptime) - end"; \
sleep 5s; \
echo "$(awk '{print $1}' /proc/uptime) - restart"; \
./mptcp_join.sh "signal address"
013 signal address
(...)
10.75 - end
15.76 - restart
013 signal address
[ 10.367935] mptcp:mptcp_pm_add_addr_echoed: MPTCP: msk=(...)
(...)
=> a delay of 5 seconds: printed with a 10.36 ts, but after 'restart'
which was printed at the 15.76 ts.
The 'Fixes' tag here below points to the first pr_debug() used without
'\n' in net/mptcp. This patch could be split in many small ones, with
different Fixes tag, but it doesn't seem worth it, because it is easy to
re-generate this patch with this simple 'sed' command:
git grep -l pr_debug -- net/mptcp |
xargs sed -i "s/\(pr_debug(\".*[^n]\)\(\"[,)]\)/\1\\\n\2/g"
So in case of conflicts, simply drop the modifications, and launch this
command.
Fixes: f870fa0b5768 ("mptcp: Add MPTCP socket stubs")
Cc: stable@vger.kernel.org
Reviewed-by: Geliang Tang <geliang@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20240826-net-mptcp-close-extra-sf-fin-v1-4-905199fe1172@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26 19:11:21 +02:00
|
|
|
|
2020-09-14 10:01:14 +02:00
|
|
|
|
|
|
|
|
|
2020-09-14 10:01:12 +02:00
|
|
|
|
2025-09-27 11:40:42 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-09-06 20:04:01 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-14 10:01:11 +02:00
|
|
|
|
2025-02-18 19:36:15 +01:00
|
|
|
|
2022-09-06 20:04:01 +02:00
|
|
|
|
|
|
|
|
|
2020-09-14 10:01:11 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-14 10:01:12 +02:00
|
|
|
|
|
|
|
|
|
2020-02-26 10:14:48 +01:00
|
|
|
|
2020-09-14 10:01:12 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-09-27 11:40:39 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-10-28 12:58:01 +01:00
|
|
|
|
2025-09-27 11:40:39 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-10-28 12:58:02 +01:00
|
|
|
|
|
|
|
|
|
2025-09-27 11:40:39 +02:00
|
|
|
|
2025-10-28 12:58:02 +01:00
|
|
|
|
2025-10-28 12:58:01 +01:00
|
|
|
|
2025-09-27 11:40:39 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-10-28 12:58:02 +01:00
|
|
|
|
2025-10-28 12:58:01 +01:00
|
|
|
|
2025-09-27 11:40:39 +02:00
|
|
|
|
2025-10-28 12:58:02 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-09-27 11:40:39 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-08-07 15:49:07 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-09-08 16:07:19 +02:00
|
|
|
|
|
|
|
|
|
2026-08-07 15:49:07 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-14 10:01:12 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-05-04 14:54:07 -07:00
|
|
|
|
2020-09-14 10:01:12 +02:00
|
|
|
|
mptcp: pr_debug: add missing \n at the end
pr_debug() have been added in various places in MPTCP code to help
developers to debug some situations. With the dynamic debug feature, it
is easy to enable all or some of them, and asks users to reproduce
issues with extra debug.
Many of these pr_debug() don't end with a new line, while no 'pr_cont()'
are used in MPTCP code. So the goal was not to display multiple debug
messages on one line: they were then not missing the '\n' on purpose.
Not having the new line at the end causes these messages to be printed
with a delay, when something else needs to be printed. This issue is not
visible when many messages need to be printed, but it is annoying and
confusing when only specific messages are expected, e.g.
# echo "func mptcp_pm_add_addr_echoed +fmp" \
> /sys/kernel/debug/dynamic_debug/control
# ./mptcp_join.sh "signal address"; \
echo "$(awk '{print $1}' /proc/uptime) - end"; \
sleep 5s; \
echo "$(awk '{print $1}' /proc/uptime) - restart"; \
./mptcp_join.sh "signal address"
013 signal address
(...)
10.75 - end
15.76 - restart
013 signal address
[ 10.367935] mptcp:mptcp_pm_add_addr_echoed: MPTCP: msk=(...)
(...)
=> a delay of 5 seconds: printed with a 10.36 ts, but after 'restart'
which was printed at the 15.76 ts.
The 'Fixes' tag here below points to the first pr_debug() used without
'\n' in net/mptcp. This patch could be split in many small ones, with
different Fixes tag, but it doesn't seem worth it, because it is easy to
re-generate this patch with this simple 'sed' command:
git grep -l pr_debug -- net/mptcp |
xargs sed -i "s/\(pr_debug(\".*[^n]\)\(\"[,)]\)/\1\\\n\2/g"
So in case of conflicts, simply drop the modifications, and launch this
command.
Fixes: f870fa0b5768 ("mptcp: Add MPTCP socket stubs")
Cc: stable@vger.kernel.org
Reviewed-by: Geliang Tang <geliang@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20240826-net-mptcp-close-extra-sf-fin-v1-4-905199fe1172@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26 19:11:21 +02:00
|
|
|
|
2020-09-14 10:01:14 +02:00
|
|
|
|
2020-11-19 11:46:02 -08:00
|
|
|
|
2020-09-14 10:01:12 +02:00
|
|
|
|
|
|
|
|
|
2020-11-19 11:46:02 -08:00
|
|
|
|
|
|
|
|
|
2022-05-04 14:54:07 -07:00
|
|
|
|
2020-09-14 10:01:14 +02:00
|
|
|
|
2020-09-14 10:01:12 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-09-08 16:07:20 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-14 10:01:12 +02:00
|
|
|
|
2020-09-14 10:01:14 +02:00
|
|
|
|
2020-09-14 10:01:12 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-14 10:01:14 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-14 10:01:12 +02:00
|
|
|
|
2020-09-14 10:01:14 +02:00
|
|
|
|
2020-09-14 10:01:12 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-14 10:01:14 +02:00
|
|
|
|
2020-09-14 10:01:12 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-14 10:01:14 +02:00
|
|
|
|
2020-09-14 10:01:12 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-14 10:01:14 +02:00
|
|
|
|
2020-09-14 10:01:12 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-14 10:01:14 +02:00
|
|
|
|
2020-09-14 10:01:12 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-14 10:01:14 +02:00
|
|
|
|
2020-09-14 10:01:12 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-14 10:01:14 +02:00
|
|
|
|
2020-09-14 10:01:12 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-02-18 19:36:15 +01:00
|
|
|
|
2020-09-14 10:01:12 +02:00
|
|
|
|
|
|
|
|
|
2025-09-27 11:40:40 +02:00
|
|
|
|
|
|
|
|
|
2020-09-14 10:01:12 +02:00
|
|
|
|
2025-11-21 18:02:11 +01:00
|
|
|
|
2025-09-27 11:40:40 +02:00
|
|
|
|
2021-06-03 16:24:32 -07:00
|
|
|
|
2020-09-14 10:01:12 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-14 10:01:11 +02:00
|
|
|
|
2021-06-03 16:24:32 -07:00
|
|
|
|
2025-02-18 19:36:13 +01:00
|
|
|
|
2020-05-25 23:41:13 +02:00
|
|
|
|
2025-09-27 11:40:40 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-11-21 18:02:11 +01:00
|
|
|
|
2025-09-27 11:40:40 +02:00
|
|
|
|
2020-09-14 10:01:12 +02:00
|
|
|
|
|
|
|
|
|
2026-08-07 15:49:06 +02:00
|
|
|
|
2026-08-07 15:49:07 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-06-20 18:30:15 +02:00
|
|
|
|
2020-10-05 17:33:26 -07:00
|
|
|
|
2020-09-14 10:01:12 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-05-25 23:41:13 +02:00
|
|
|
|
2025-02-18 19:36:15 +01:00
|
|
|
|
2020-09-14 10:01:12 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-08-07 15:49:06 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-05-15 06:27:32 +02:00
|
|
|
|
|
|
|
|
|
2026-08-07 15:49:06 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-02-26 10:14:48 +01:00
|
|
|
|
|
|
|
|
|
2023-09-16 12:52:48 +02:00
|
|
|
|
2020-07-28 15:12:05 -07:00
|
|
|
|
2025-11-24 17:50:13 +00:00
|
|
|
|
2020-07-28 15:12:05 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-16 10:48:09 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
mptcp: propagate shutdown to subflows when possible
When the MPTCP DATA FIN have been ACKed, there is no more MPTCP related
metadata to exchange, and all subflows can be safely shutdown.
Before this patch, the subflows were actually terminated at 'close()'
time. That's certainly fine most of the time, but not when the userspace
'shutdown()' a connection, without close()ing it. When doing so, the
subflows were staying in LAST_ACK state on one side -- and consequently
in FIN_WAIT2 on the other side -- until the 'close()' of the MPTCP
socket.
Now, when the DATA FIN have been ACKed, all subflows are shutdown. A
consequence of this is that the TCP 'FIN' flag can be set earlier now,
but the end result is the same. This affects the packetdrill tests
looking at the end of the MPTCP connections, but for a good reason.
Note that tcp_shutdown() will check the subflow state, so no need to do
that again before calling it.
Fixes: 3721b9b64676 ("mptcp: Track received DATA_FIN sequence number and add related helpers")
Cc: stable@vger.kernel.org
Fixes: 16a9a9da1723 ("mptcp: Add helper to process acks of DATA_FIN")
Reviewed-by: Mat Martineau <martineau@kernel.org>
Reviewed-by: Geliang Tang <geliang@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20250912-net-mptcp-fix-sft-connect-v1-1-d40e77cbbf02@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-12 14:25:50 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-02-02 12:40:09 +01:00
|
|
|
|
2020-11-27 11:10:27 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-06-20 18:24:21 +02:00
|
|
|
|
2020-11-27 11:10:27 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-07-28 15:12:05 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-27 11:10:27 +01:00
|
|
|
|
2020-07-28 15:12:05 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-12-22 13:47:23 +01:00
|
|
|
|
2020-07-28 15:12:05 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
mptcp: propagate shutdown to subflows when possible
When the MPTCP DATA FIN have been ACKed, there is no more MPTCP related
metadata to exchange, and all subflows can be safely shutdown.
Before this patch, the subflows were actually terminated at 'close()'
time. That's certainly fine most of the time, but not when the userspace
'shutdown()' a connection, without close()ing it. When doing so, the
subflows were staying in LAST_ACK state on one side -- and consequently
in FIN_WAIT2 on the other side -- until the 'close()' of the MPTCP
socket.
Now, when the DATA FIN have been ACKed, all subflows are shutdown. A
consequence of this is that the TCP 'FIN' flag can be set earlier now,
but the end result is the same. This affects the packetdrill tests
looking at the end of the MPTCP connections, but for a good reason.
Note that tcp_shutdown() will check the subflow state, so no need to do
that again before calling it.
Fixes: 3721b9b64676 ("mptcp: Track received DATA_FIN sequence number and add related helpers")
Cc: stable@vger.kernel.org
Fixes: 16a9a9da1723 ("mptcp: Add helper to process acks of DATA_FIN")
Reviewed-by: Mat Martineau <martineau@kernel.org>
Reviewed-by: Geliang Tang <geliang@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20250912-net-mptcp-fix-sft-connect-v1-1-d40e77cbbf02@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-12 14:25:50 +02:00
|
|
|
|
2023-12-22 13:47:23 +01:00
|
|
|
|
2020-07-28 15:12:05 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-16 10:48:09 +01:00
|
|
|
|
2020-07-28 15:12:05 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-02-02 12:40:09 +01:00
|
|
|
|
2020-07-28 15:12:03 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-02-02 12:40:09 +01:00
|
|
|
|
2020-07-28 15:12:03 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-02-02 12:40:09 +01:00
|
|
|
|
2020-07-28 15:12:03 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-03-17 15:55:38 +00:00
|
|
|
|
2021-04-23 09:40:33 -07:00
|
|
|
|
|
|
|
|
|
2026-08-12 16:55:39 +02:00
|
|
|
|
|
|
|
|
|
2022-02-24 16:52:59 -08:00
|
|
|
|
2021-04-23 09:40:33 -07:00
|
|
|
|
2026-08-12 16:55:39 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-02-24 16:52:59 -08:00
|
|
|
|
2026-08-12 16:55:39 +02:00
|
|
|
|
2022-02-24 16:52:59 -08:00
|
|
|
|
2026-08-12 16:55:39 +02:00
|
|
|
|
2021-04-23 09:40:33 -07:00
|
|
|
|
|
|
|
|
|
2021-08-13 15:15:41 -07:00
|
|
|
|
2020-07-28 15:12:03 -07:00
|
|
|
|
2026-08-12 16:55:39 +02:00
|
|
|
|
|
|
|
|
|
2020-07-28 15:12:03 -07:00
|
|
|
|
|
|
|
|
|
2021-08-13 15:15:41 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-08-13 15:15:42 -07:00
|
|
|
|
2025-11-24 17:50:10 +00:00
|
|
|
|
2021-08-13 15:15:41 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-06-27 18:02:37 -07:00
|
|
|
|
2020-11-24 22:51:24 +01:00
|
|
|
|
|
|
|
|
|
2021-01-12 18:25:23 +01:00
|
|
|
|
2020-11-24 22:51:24 +01:00
|
|
|
|
|
|
|
|
|
2022-07-05 14:32:13 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-07-11 12:16:29 -07:00
|
|
|
|
2021-09-02 11:51:19 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-07-05 14:32:13 -07:00
|
|
|
|
2021-09-02 11:51:19 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-24 22:51:24 +01:00
|
|
|
|
2020-11-16 10:48:14 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-09-02 11:51:19 -07:00
|
|
|
|
|
|
|
|
|
2020-11-24 22:51:24 +01:00
|
|
|
|
2020-11-19 11:46:03 -08:00
|
|
|
|
2024-12-30 19:12:31 +01:00
|
|
|
|
2020-11-24 22:51:24 +01:00
|
|
|
|
2021-06-21 15:54:34 -07:00
|
|
|
|
2020-11-24 22:51:24 +01:00
|
|
|
|
2021-06-21 15:54:34 -07:00
|
|
|
|
2021-06-22 12:25:23 -07:00
|
|
|
|
2024-12-30 19:12:31 +01:00
|
|
|
|
2021-06-21 15:54:34 -07:00
|
|
|
|
2021-06-22 12:25:23 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-06-25 14:25:22 -07:00
|
|
|
|
2021-06-22 12:25:23 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-24 22:51:24 +01:00
|
|
|
|
|
|
|
|
|
2024-12-30 19:12:31 +01:00
|
|
|
|
2020-11-24 22:51:24 +01:00
|
|
|
|
2021-02-11 15:30:41 -08:00
|
|
|
|
2020-11-24 22:51:24 +01:00
|
|
|
|
2021-02-11 15:30:41 -08:00
|
|
|
|
2021-06-22 12:25:23 -07:00
|
|
|
|
|
|
|
|
|
2021-02-11 15:30:41 -08:00
|
|
|
|
2024-12-30 19:12:31 +01:00
|
|
|
|
2025-02-18 19:36:17 +01:00
|
|
|
|
2020-11-24 22:51:24 +01:00
|
|
|
|
2021-06-22 12:25:23 -07:00
|
|
|
|
|
|
|
|
|
2020-11-24 22:51:24 +01:00
|
|
|
|
2021-06-22 12:25:23 -07:00
|
|
|
|
2024-12-30 19:12:31 +01:00
|
|
|
|
2020-11-16 10:48:14 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-09-19 14:09:03 +02:00
|
|
|
|
2020-07-28 15:12:03 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-29 15:08:19 -07:00
|
|
|
|
2020-07-28 15:12:03 -07:00
|
|
|
|
|
|
|
|
|
2023-05-31 12:37:07 -07:00
|
|
|
|
2020-07-28 15:12:05 -07:00
|
|
|
|
2020-07-28 15:12:03 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-12-22 13:47:23 +01:00
|
|
|
|
2020-07-28 15:12:03 -07:00
|
|
|
|
|
|
|
|
|
2023-12-22 13:47:23 +01:00
|
|
|
|
2020-07-28 15:12:03 -07:00
|
|
|
|
|
|
|
|
|
mptcp: propagate shutdown to subflows when possible
When the MPTCP DATA FIN have been ACKed, there is no more MPTCP related
metadata to exchange, and all subflows can be safely shutdown.
Before this patch, the subflows were actually terminated at 'close()'
time. That's certainly fine most of the time, but not when the userspace
'shutdown()' a connection, without close()ing it. When doing so, the
subflows were staying in LAST_ACK state on one side -- and consequently
in FIN_WAIT2 on the other side -- until the 'close()' of the MPTCP
socket.
Now, when the DATA FIN have been ACKed, all subflows are shutdown. A
consequence of this is that the TCP 'FIN' flag can be set earlier now,
but the end result is the same. This affects the packetdrill tests
looking at the end of the MPTCP connections, but for a good reason.
Note that tcp_shutdown() will check the subflow state, so no need to do
that again before calling it.
Fixes: 3721b9b64676 ("mptcp: Track received DATA_FIN sequence number and add related helpers")
Cc: stable@vger.kernel.org
Fixes: 16a9a9da1723 ("mptcp: Add helper to process acks of DATA_FIN")
Reviewed-by: Mat Martineau <martineau@kernel.org>
Reviewed-by: Geliang Tang <geliang@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20250912-net-mptcp-fix-sft-connect-v1-1-d40e77cbbf02@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-12 14:25:50 +02:00
|
|
|
|
2023-12-22 13:47:23 +01:00
|
|
|
|
2020-07-28 15:12:03 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-06-20 18:24:21 +02:00
|
|
|
|
|
|
|
|
|
2020-11-16 10:48:09 +01:00
|
|
|
|
2020-07-28 15:12:03 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-10-08 13:04:52 +02:00
|
|
|
|
|
|
|
|
|
2025-07-23 16:32:23 +02:00
|
|
|
|
2024-10-08 13:04:52 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-11-21 18:02:12 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-11-21 18:02:13 +01:00
|
|
|
|
2025-11-21 18:02:12 +01:00
|
|
|
|
2026-08-07 15:49:04 +02:00
|
|
|
|
2025-11-21 18:02:12 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-08-07 15:49:04 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-11-21 18:02:12 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-11-21 18:02:13 +01:00
|
|
|
|
2025-11-21 18:02:12 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-11-21 18:02:13 +01:00
|
|
|
|
2025-11-21 18:02:12 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-11-21 18:02:13 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-11-21 18:02:12 +01:00
|
|
|
|
|
|
|
|
|
2020-02-26 10:14:48 +01:00
|
|
|
|
2025-11-21 18:02:13 +01:00
|
|
|
|
2020-02-26 10:14:48 +01:00
|
|
|
|
|
|
|
|
|
2020-02-26 10:14:49 +01:00
|
|
|
|
2020-02-26 10:14:48 +01:00
|
|
|
|
|
|
|
|
|
2025-02-18 19:36:18 +01:00
|
|
|
|
2020-02-26 10:14:49 +01:00
|
|
|
|
mptcp: pr_debug: add missing \n at the end
pr_debug() have been added in various places in MPTCP code to help
developers to debug some situations. With the dynamic debug feature, it
is easy to enable all or some of them, and asks users to reproduce
issues with extra debug.
Many of these pr_debug() don't end with a new line, while no 'pr_cont()'
are used in MPTCP code. So the goal was not to display multiple debug
messages on one line: they were then not missing the '\n' on purpose.
Not having the new line at the end causes these messages to be printed
with a delay, when something else needs to be printed. This issue is not
visible when many messages need to be printed, but it is annoying and
confusing when only specific messages are expected, e.g.
# echo "func mptcp_pm_add_addr_echoed +fmp" \
> /sys/kernel/debug/dynamic_debug/control
# ./mptcp_join.sh "signal address"; \
echo "$(awk '{print $1}' /proc/uptime) - end"; \
sleep 5s; \
echo "$(awk '{print $1}' /proc/uptime) - restart"; \
./mptcp_join.sh "signal address"
013 signal address
(...)
10.75 - end
15.76 - restart
013 signal address
[ 10.367935] mptcp:mptcp_pm_add_addr_echoed: MPTCP: msk=(...)
(...)
=> a delay of 5 seconds: printed with a 10.36 ts, but after 'restart'
which was printed at the 15.76 ts.
The 'Fixes' tag here below points to the first pr_debug() used without
'\n' in net/mptcp. This patch could be split in many small ones, with
different Fixes tag, but it doesn't seem worth it, because it is easy to
re-generate this patch with this simple 'sed' command:
git grep -l pr_debug -- net/mptcp |
xargs sed -i "s/\(pr_debug(\".*[^n]\)\(\"[,)]\)/\1\\\n\2/g"
So in case of conflicts, simply drop the modifications, and launch this
command.
Fixes: f870fa0b5768 ("mptcp: Add MPTCP socket stubs")
Cc: stable@vger.kernel.org
Reviewed-by: Geliang Tang <geliang@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20240826-net-mptcp-close-extra-sf-fin-v1-4-905199fe1172@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26 19:11:21 +02:00
|
|
|
|
2020-02-26 10:14:48 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-02-18 19:36:18 +01:00
|
|
|
|
2020-02-26 10:14:48 +01:00
|
|
|
|
|
|
|
|
|
2020-06-29 22:26:20 +02:00
|
|
|
|
2022-09-30 08:59:34 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-06-29 22:26:20 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-02-26 10:14:48 +01:00
|
|
|
|
|
|
|
|
|
2025-02-18 19:36:18 +01:00
|
|
|
|
2020-02-26 10:14:48 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-09-27 11:40:40 +02:00
|
|
|
|
2025-11-21 18:02:12 +01:00
|
|
|
|
2026-08-07 15:49:04 +02:00
|
|
|
|
2025-11-21 18:02:12 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-02-26 10:14:48 +01:00
|
|
|
|
|
|
|
|
|
2024-10-08 13:04:52 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-02-26 10:14:48 +01:00
|
|
|
|
2026-09-17 15:05:57 +02:00
|
|
|
|
|
|
|
|
|
2024-10-08 13:04:52 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-02-26 10:14:48 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-02-26 10:14:49 +01:00
|
|
|
|
2020-02-26 10:14:48 +01:00
|
|
|
|
|
|
|
|
|
2025-02-18 19:36:18 +01:00
|
|
|
|
mptcp: add last time fields in mptcp_info
This patch adds "last time" fields last_data_sent, last_data_recv and
last_ack_recv in struct mptcp_sock to record the last time data_sent,
data_recv and ack_recv happened. They all are initialized as
tcp_jiffies32 in __mptcp_init_sock(), and updated as tcp_jiffies32 too
when data is sent in __subflow_push_pending(), data is received in
__mptcp_move_skbs_from_subflow(), and ack is received in ack_update_msk().
Similar to tcpi_last_data_sent, tcpi_last_data_recv and tcpi_last_ack_recv
exposed with TCP, this patch exposes the last time "an action happened" for
MPTCP in mptcp_info, named mptcpi_last_data_sent, mptcpi_last_data_recv and
mptcpi_last_ack_recv, calculated in mptcp_diag_fill_info() as the time
deltas between now and the newly added last time fields in mptcp_sock.
Since msk->last_ack_recv needs to be protected by mptcp_data_lock/unlock,
and lock_sock_fast can sleep and be quite slow, move the entire
mptcp_data_lock/unlock block after the lock/unlock_sock_fast block.
Then mptcpi_last_data_sent and mptcpi_last_data_recv are set in
lock/unlock_sock_fast block, while mptcpi_last_ack_recv is set in
mptcp_data_lock/unlock block, which is protected by a spinlock and
should not block for too long.
Also add three reserved bytes in struct mptcp_info not to have holes in
this structure exposed to userspace.
Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/446
Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn>
Reviewed-by: Mat Martineau <martineau@kernel.org>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://lore.kernel.org/r/20240410-upstream-net-next-20240405-mptcp-last-time-info-v2-1-f95bd6b33e51@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-04-10 11:48:24 +02:00
|
|
|
|
2025-02-18 19:36:18 +01:00
|
|
|
|
2020-02-26 10:14:48 +01:00
|
|
|
|
|
|
|
|
|
2020-11-27 11:10:24 +01:00
|
|
|
|
2020-09-14 10:01:12 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
mptcp: pr_debug: add missing \n at the end
pr_debug() have been added in various places in MPTCP code to help
developers to debug some situations. With the dynamic debug feature, it
is easy to enable all or some of them, and asks users to reproduce
issues with extra debug.
Many of these pr_debug() don't end with a new line, while no 'pr_cont()'
are used in MPTCP code. So the goal was not to display multiple debug
messages on one line: they were then not missing the '\n' on purpose.
Not having the new line at the end causes these messages to be printed
with a delay, when something else needs to be printed. This issue is not
visible when many messages need to be printed, but it is annoying and
confusing when only specific messages are expected, e.g.
# echo "func mptcp_pm_add_addr_echoed +fmp" \
> /sys/kernel/debug/dynamic_debug/control
# ./mptcp_join.sh "signal address"; \
echo "$(awk '{print $1}' /proc/uptime) - end"; \
sleep 5s; \
echo "$(awk '{print $1}' /proc/uptime) - restart"; \
./mptcp_join.sh "signal address"
013 signal address
(...)
10.75 - end
15.76 - restart
013 signal address
[ 10.367935] mptcp:mptcp_pm_add_addr_echoed: MPTCP: msk=(...)
(...)
=> a delay of 5 seconds: printed with a 10.36 ts, but after 'restart'
which was printed at the 15.76 ts.
The 'Fixes' tag here below points to the first pr_debug() used without
'\n' in net/mptcp. This patch could be split in many small ones, with
different Fixes tag, but it doesn't seem worth it, because it is easy to
re-generate this patch with this simple 'sed' command:
git grep -l pr_debug -- net/mptcp |
xargs sed -i "s/\(pr_debug(\".*[^n]\)\(\"[,)]\)/\1\\\n\2/g"
So in case of conflicts, simply drop the modifications, and launch this
command.
Fixes: f870fa0b5768 ("mptcp: Add MPTCP socket stubs")
Cc: stable@vger.kernel.org
Reviewed-by: Geliang Tang <geliang@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20240826-net-mptcp-close-extra-sf-fin-v1-4-905199fe1172@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26 19:11:21 +02:00
|
|
|
|
2020-09-14 10:01:12 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-14 10:01:14 +02:00
|
|
|
|
2020-09-14 10:01:12 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
mptcp: pr_debug: add missing \n at the end
pr_debug() have been added in various places in MPTCP code to help
developers to debug some situations. With the dynamic debug feature, it
is easy to enable all or some of them, and asks users to reproduce
issues with extra debug.
Many of these pr_debug() don't end with a new line, while no 'pr_cont()'
are used in MPTCP code. So the goal was not to display multiple debug
messages on one line: they were then not missing the '\n' on purpose.
Not having the new line at the end causes these messages to be printed
with a delay, when something else needs to be printed. This issue is not
visible when many messages need to be printed, but it is annoying and
confusing when only specific messages are expected, e.g.
# echo "func mptcp_pm_add_addr_echoed +fmp" \
> /sys/kernel/debug/dynamic_debug/control
# ./mptcp_join.sh "signal address"; \
echo "$(awk '{print $1}' /proc/uptime) - end"; \
sleep 5s; \
echo "$(awk '{print $1}' /proc/uptime) - restart"; \
./mptcp_join.sh "signal address"
013 signal address
(...)
10.75 - end
15.76 - restart
013 signal address
[ 10.367935] mptcp:mptcp_pm_add_addr_echoed: MPTCP: msk=(...)
(...)
=> a delay of 5 seconds: printed with a 10.36 ts, but after 'restart'
which was printed at the 15.76 ts.
The 'Fixes' tag here below points to the first pr_debug() used without
'\n' in net/mptcp. This patch could be split in many small ones, with
different Fixes tag, but it doesn't seem worth it, because it is easy to
re-generate this patch with this simple 'sed' command:
git grep -l pr_debug -- net/mptcp |
xargs sed -i "s/\(pr_debug(\".*[^n]\)\(\"[,)]\)/\1\\\n\2/g"
So in case of conflicts, simply drop the modifications, and launch this
command.
Fixes: f870fa0b5768 ("mptcp: Add MPTCP socket stubs")
Cc: stable@vger.kernel.org
Reviewed-by: Geliang Tang <geliang@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20240826-net-mptcp-close-extra-sf-fin-v1-4-905199fe1172@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26 19:11:21 +02:00
|
|
|
|
2020-09-14 10:01:14 +02:00
|
|
|
|
|
|
|
|
|
2020-09-14 10:01:12 +02:00
|
|
|
|
2021-12-03 14:35:32 -08:00
|
|
|
|
2020-09-14 10:01:12 +02:00
|
|
|
|
|
|
|
|
|
2023-06-20 18:30:15 +02:00
|
|
|
|
2024-02-02 12:40:09 +01:00
|
|
|
|
2020-09-14 10:01:12 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-09-16 12:52:47 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-01-27 20:27:25 +01:00
|
|
|
|
2023-09-16 12:52:47 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-01-27 20:27:25 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-09-16 12:52:47 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-12-22 13:47:23 +01:00
|
|
|
|
2023-09-16 12:52:47 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-09-16 12:52:46 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-09-16 12:52:47 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-09-16 12:52:46 +02:00
|
|
|
|
|
|
|
|
|
2020-02-26 10:14:51 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
mptcp: wake-up readers only for in sequence data
Currently we rely on the subflow->data_avail field, which is subject to
races:
ssk1
skb len = 500 DSS(seq=1, len=1000, off=0)
# data_avail == MPTCP_SUBFLOW_DATA_AVAIL
ssk2
skb len = 500 DSS(seq = 501, len=1000)
# data_avail == MPTCP_SUBFLOW_DATA_AVAIL
ssk1
skb len = 500 DSS(seq = 1, len=1000, off =500)
# still data_avail == MPTCP_SUBFLOW_DATA_AVAIL,
# as the skb is covered by a pre-existing map,
# which was in-sequence at reception time.
Instead we can explicitly check if some has been received in-sequence,
propagating the info from __mptcp_move_skbs_from_subflow().
Additionally add the 'ONCE' annotation to the 'data_avail' memory
access, as msk will read it outside the subflow socket lock.
Fixes: 648ef4b88673 ("mptcp: Implement MPTCP receive path")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-10 15:59:41 -07:00
|
|
|
|
2020-02-26 10:14:51 +01:00
|
|
|
|
|
|
|
|
|
2025-02-18 19:36:18 +01:00
|
|
|
|
2020-02-26 10:14:51 +01:00
|
|
|
|
2025-11-21 18:02:13 +01:00
|
|
|
|
2020-11-27 11:10:24 +01:00
|
|
|
|
2025-09-27 11:40:43 +02:00
|
|
|
|
|
|
|
|
|
2020-09-14 10:01:12 +02:00
|
|
|
|
2020-11-27 11:10:24 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-02-18 19:36:18 +01:00
|
|
|
|
2020-02-26 10:14:51 +01:00
|
|
|
|
|
|
|
|
|
mptcp: better mptcp-level RTT estimator
The current MPTCP-level RTT estimator has several issues. On high speed
links, the MPTCP-level receive buffer auto-tuning happens with a
frequency well above the TCP-level's one. That in turn can cause
excessive/unneeded receive buffer increase.
On such links, the initial rtt_us value is considerably higher than the
actual delay, and the current mptcp_rcv_space_adjust() updates
msk->rcvq_space.rtt_us with a period equal to the such field previous
value. If the initial rtt_us is 40ms, its first update will happen after
40ms, even if the subflows see actual RTT orders of magnitude lower.
Additionally:
- setting the msk RTT to the maximum among all the subflows RTTs makes
DRS constantly overshooting the rcvbuf size when a subflow has
considerable higher latency than the other(s).
- during unidirectional bulk transfers with multiple active subflows,
the TCP-level RTT estimator occasionally sees considerably higher
value than the real link delay, i.e. when the packet scheduler reacts
to an incoming ACK on given subflow pushing data on a different
subflow.
- currently inactive but still open subflows (i.e. switched to backup
mode) are always considered when computing the msk-level RTT.
Address the all the issues above with a more accurate RTT estimation
strategy: the MPTCP-level RTT is set to the minimum of all the subflows
actually feeding data into the MPTCP receive buffer, using a small
sliding window.
While at it, also use EWMA to compute the msk-level scaling_ratio, to
that MPTCP can avoid traversing the subflow list is
mptcp_rcv_space_adjust().
Use some care to avoid updating msk and ssk level fields too often.
Fixes: a6b118febbab ("mptcp: add receive buffer auto-tuning")
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/20260407-net-next-mptcp-reduce-rbuf-v2-1-0d1d135bf6f6@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-07 10:45:17 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-02-26 10:14:51 +01:00
|
|
|
|
2020-02-26 10:14:46 +01:00
|
|
|
|
2020-09-14 10:01:09 +02:00
|
|
|
|
2025-11-21 18:02:09 +01:00
|
|
|
|
2020-02-26 10:14:46 +01:00
|
|
|
|
2020-12-09 12:03:31 +01:00
|
|
|
|
2025-11-21 18:02:10 +01:00
|
|
|
|
2020-12-09 12:03:31 +01:00
|
|
|
|
|
|
|
|
|
2025-11-21 18:02:10 +01:00
|
|
|
|
2020-12-09 12:03:31 +01:00
|
|
|
|
|
|
|
|
|
mptcp: wake-up readers only for in sequence data
Currently we rely on the subflow->data_avail field, which is subject to
races:
ssk1
skb len = 500 DSS(seq=1, len=1000, off=0)
# data_avail == MPTCP_SUBFLOW_DATA_AVAIL
ssk2
skb len = 500 DSS(seq = 501, len=1000)
# data_avail == MPTCP_SUBFLOW_DATA_AVAIL
ssk1
skb len = 500 DSS(seq = 1, len=1000, off =500)
# still data_avail == MPTCP_SUBFLOW_DATA_AVAIL,
# as the skb is covered by a pre-existing map,
# which was in-sequence at reception time.
Instead we can explicitly check if some has been received in-sequence,
propagating the info from __mptcp_move_skbs_from_subflow().
Additionally add the 'ONCE' annotation to the 'data_avail' memory
access, as msk will read it outside the subflow socket lock.
Fixes: 648ef4b88673 ("mptcp: Implement MPTCP receive path")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-10 15:59:41 -07:00
|
|
|
|
mptcp: better mptcp-level RTT estimator
The current MPTCP-level RTT estimator has several issues. On high speed
links, the MPTCP-level receive buffer auto-tuning happens with a
frequency well above the TCP-level's one. That in turn can cause
excessive/unneeded receive buffer increase.
On such links, the initial rtt_us value is considerably higher than the
actual delay, and the current mptcp_rcv_space_adjust() updates
msk->rcvq_space.rtt_us with a period equal to the such field previous
value. If the initial rtt_us is 40ms, its first update will happen after
40ms, even if the subflows see actual RTT orders of magnitude lower.
Additionally:
- setting the msk RTT to the maximum among all the subflows RTTs makes
DRS constantly overshooting the rcvbuf size when a subflow has
considerable higher latency than the other(s).
- during unidirectional bulk transfers with multiple active subflows,
the TCP-level RTT estimator occasionally sees considerably higher
value than the real link delay, i.e. when the packet scheduler reacts
to an incoming ACK on given subflow pushing data on a different
subflow.
- currently inactive but still open subflows (i.e. switched to backup
mode) are always considered when computing the msk-level RTT.
Address the all the issues above with a more accurate RTT estimation
strategy: the MPTCP-level RTT is set to the minimum of all the subflows
actually feeding data into the MPTCP receive buffer, using a small
sliding window.
While at it, also use EWMA to compute the msk-level scaling_ratio, to
that MPTCP can avoid traversing the subflow list is
mptcp_rcv_space_adjust().
Use some care to avoid updating msk and ssk level fields too often.
Fixes: a6b118febbab ("mptcp: add receive buffer auto-tuning")
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/20260407-net-next-mptcp-reduce-rbuf-v2-1-0d1d135bf6f6@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-07 10:45:17 +02:00
|
|
|
|
2025-11-21 18:02:09 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-11-21 18:02:13 +01:00
|
|
|
|
2025-11-21 18:02:09 +01:00
|
|
|
|
mptcp: wake-up readers only for in sequence data
Currently we rely on the subflow->data_avail field, which is subject to
races:
ssk1
skb len = 500 DSS(seq=1, len=1000, off=0)
# data_avail == MPTCP_SUBFLOW_DATA_AVAIL
ssk2
skb len = 500 DSS(seq = 501, len=1000)
# data_avail == MPTCP_SUBFLOW_DATA_AVAIL
ssk1
skb len = 500 DSS(seq = 1, len=1000, off =500)
# still data_avail == MPTCP_SUBFLOW_DATA_AVAIL,
# as the skb is covered by a pre-existing map,
# which was in-sequence at reception time.
Instead we can explicitly check if some has been received in-sequence,
propagating the info from __mptcp_move_skbs_from_subflow().
Additionally add the 'ONCE' annotation to the 'data_avail' memory
access, as msk will read it outside the subflow socket lock.
Fixes: 648ef4b88673 ("mptcp: Implement MPTCP receive path")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-06-10 15:59:41 -07:00
|
|
|
|
2020-02-26 10:14:46 +01:00
|
|
|
|
|
|
|
|
|
2023-05-31 12:37:08 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-07-14 18:41:45 +02:00
|
|
|
|
2023-05-31 12:37:08 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-01-06 16:20:25 -08:00
|
|
|
|
2020-03-27 14:48:40 -07:00
|
|
|
|
2022-01-06 16:20:25 -08:00
|
|
|
|
2021-01-20 15:39:11 +01:00
|
|
|
|
2022-01-06 16:20:25 -08:00
|
|
|
|
2021-04-15 16:44:53 -07:00
|
|
|
|
2020-03-27 14:48:40 -07:00
|
|
|
|
2025-07-14 18:41:44 +02:00
|
|
|
|
2025-07-14 18:41:45 +02:00
|
|
|
|
2025-07-14 18:41:44 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-06-20 18:30:17 +02:00
|
|
|
|
2022-01-06 16:20:25 -08:00
|
|
|
|
2023-09-16 12:52:49 +02:00
|
|
|
|
2023-10-23 13:44:42 -07:00
|
|
|
|
2022-01-06 16:20:25 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-06-20 18:24:20 +02:00
|
|
|
|
2022-01-06 16:20:25 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-06-20 18:24:20 +02:00
|
|
|
|
2022-01-06 16:20:25 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-04-15 16:44:54 -07:00
|
|
|
|
2020-03-27 14:48:40 -07:00
|
|
|
|
|
|
|
|
|
2023-09-16 12:52:48 +02:00
|
|
|
|
2020-03-27 14:48:44 -07:00
|
|
|
|
2025-11-24 17:50:13 +00:00
|
|
|
|
2020-03-27 14:48:44 -07:00
|
|
|
|
|
|
|
|
|
2023-09-16 12:52:48 +02:00
|
|
|
|
2020-03-27 14:48:44 -07:00
|
|
|
|
2026-09-08 16:07:06 +02:00
|
|
|
|
2020-03-27 14:48:44 -07:00
|
|
|
|
|
|
|
|
|
2026-09-08 16:07:06 +02:00
|
|
|
|
|
|
|
|
|
2020-11-16 10:48:09 +01:00
|
|
|
|
|
|
|
|
|
2026-09-08 16:07:06 +02:00
|
|
|
|
2025-11-24 17:50:13 +00:00
|
|
|
|
2020-03-27 14:48:44 -07:00
|
|
|
|
|
|
|
|
|
2020-11-16 10:48:05 +01:00
|
|
|
|
|
|
|
|
|
2025-11-13 10:39:24 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-16 10:48:05 +01:00
|
|
|
|
2025-11-13 10:39:24 +00:00
|
|
|
|
|
|
|
|
|
2020-11-16 10:48:05 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-03-27 14:48:47 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-01-21 16:56:23 -08:00
|
|
|
|
2020-01-21 16:56:27 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-03 11:05:05 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-01-21 16:56:27 -08:00
|
|
|
|
|
|
|
|
|
2021-05-11 19:13:51 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-03-27 14:48:43 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-04-03 13:29:28 +02:00
|
|
|
|
|
|
|
|
|
2020-11-16 10:48:10 +01:00
|
|
|
|
2021-05-11 19:13:51 +02:00
|
|
|
|
2020-03-27 14:48:43 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-03-27 14:48:45 -07:00
|
|
|
|
2020-03-27 14:48:43 -07:00
|
|
|
|
2020-03-27 14:48:45 -07:00
|
|
|
|
2020-03-27 14:48:46 -07:00
|
|
|
|
2020-03-27 14:48:45 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-03-27 14:48:43 -07:00
|
|
|
|
2020-03-27 14:48:45 -07:00
|
|
|
|
2020-03-27 14:48:43 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-02-02 12:40:09 +01:00
|
|
|
|
2020-11-27 11:10:27 +01:00
|
|
|
|
2020-03-27 14:48:43 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-06-29 22:26:20 +02:00
|
|
|
|
|
|
|
|
|
2020-11-27 11:10:26 +01:00
|
|
|
|
2020-03-27 14:48:43 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-08-13 15:15:43 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-10-28 09:16:52 +01:00
|
|
|
|
2021-08-13 15:15:43 -07:00
|
|
|
|
|
|
|
|
|
2020-03-27 14:48:45 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-03-27 14:48:46 -07:00
|
|
|
|
|
|
|
|
|
2020-07-23 13:02:30 +02:00
|
|
|
|
|
|
|
|
|
2021-08-13 15:15:43 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-03-27 14:48:46 -07:00
|
|
|
|
|
|
|
|
|
2020-07-23 13:02:30 +02:00
|
|
|
|
2020-03-27 14:48:46 -07:00
|
|
|
|
2020-11-16 10:48:10 +01:00
|
|
|
|
2020-03-27 14:48:46 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-08-13 15:15:43 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-07-23 13:02:30 +02:00
|
|
|
|
2024-02-02 12:40:08 +01:00
|
|
|
|
2023-09-16 12:52:48 +02:00
|
|
|
|
|
|
|
|
|
2020-11-27 11:10:27 +01:00
|
|
|
|
2023-09-16 12:52:48 +02:00
|
|
|
|
2020-03-27 14:48:43 -07:00
|
|
|
|
2024-02-02 12:40:08 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-03-27 14:48:43 -07:00
|
|
|
|
|
|
|
|
|
2021-03-04 13:32:15 -08:00
|
|
|
|
|
|
|
|
|
2021-09-24 14:12:36 -07:00
|
|
|
|
|
|
|
|
|
2021-03-04 13:32:15 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-27 11:10:25 +01:00
|
|
|
|
2020-03-27 14:48:43 -07:00
|
|
|
|
2020-11-16 10:48:10 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
net: Allow opt-out from global protocol memory accounting.
Some protocols (e.g., TCP, UDP) implement memory accounting for socket
buffers and charge memory to per-protocol global counters pointed to by
sk->sk_proto->memory_allocated.
Sometimes, system processes do not want that limitation. For a similar
purpose, there is SO_RESERVE_MEM for sockets under memcg.
Also, by opting out of the per-protocol accounting, sockets under memcg
can avoid paying costs for two orthogonal memory accounting mechanisms.
A microbenchmark result is in the subsequent bpf patch.
Let's allow opt-out from the per-protocol memory accounting if
sk->sk_bypass_prot_mem is true.
sk->sk_bypass_prot_mem and sk->sk_prot are placed in the same cache
line, and sk_has_account() always fetches sk->sk_prot before accessing
sk->sk_bypass_prot_mem, so there is no extra cache miss for this patch.
The following patches will set sk->sk_bypass_prot_mem to true, and
then, the per-protocol memory accounting will be skipped.
Note that this does NOT disable memcg, but rather the per-protocol one.
Another option not to use the hole in struct sock_common is create
sk_prot variants like tcp_prot_bypass, but this would complicate
SOCKMAP logic, tcp_bpf_prots etc.
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
Reviewed-by: Shakeel Butt <shakeel.butt@linux.dev>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Acked-by: Roman Gushchin <roman.gushchin@linux.dev>
Link: https://patch.msgid.link/20251014235604.3057003-3-kuniyu@google.com
2025-10-14 23:54:55 +00:00
|
|
|
|
2020-11-16 10:48:10 +01:00
|
|
|
|
net: Allow opt-out from global protocol memory accounting.
Some protocols (e.g., TCP, UDP) implement memory accounting for socket
buffers and charge memory to per-protocol global counters pointed to by
sk->sk_proto->memory_allocated.
Sometimes, system processes do not want that limitation. For a similar
purpose, there is SO_RESERVE_MEM for sockets under memcg.
Also, by opting out of the per-protocol accounting, sockets under memcg
can avoid paying costs for two orthogonal memory accounting mechanisms.
A microbenchmark result is in the subsequent bpf patch.
Let's allow opt-out from the per-protocol memory accounting if
sk->sk_bypass_prot_mem is true.
sk->sk_bypass_prot_mem and sk->sk_prot are placed in the same cache
line, and sk_has_account() always fetches sk->sk_prot before accessing
sk->sk_bypass_prot_mem, so there is no extra cache miss for this patch.
The following patches will set sk->sk_bypass_prot_mem to true, and
then, the per-protocol memory accounting will be skipped.
Note that this does NOT disable memcg, but rather the per-protocol one.
Another option not to use the hole in struct sock_common is create
sk_prot variants like tcp_prot_bypass, but this would complicate
SOCKMAP logic, tcp_bpf_prots etc.
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
Reviewed-by: Shakeel Butt <shakeel.butt@linux.dev>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Acked-by: Roman Gushchin <roman.gushchin@linux.dev>
Link: https://patch.msgid.link/20251014235604.3057003-3-kuniyu@google.com
2025-10-14 23:54:55 +00:00
|
|
|
|
|
|
|
|
|
2023-10-23 13:44:42 -07:00
|
|
|
|
net: Allow opt-out from global protocol memory accounting.
Some protocols (e.g., TCP, UDP) implement memory accounting for socket
buffers and charge memory to per-protocol global counters pointed to by
sk->sk_proto->memory_allocated.
Sometimes, system processes do not want that limitation. For a similar
purpose, there is SO_RESERVE_MEM for sockets under memcg.
Also, by opting out of the per-protocol accounting, sockets under memcg
can avoid paying costs for two orthogonal memory accounting mechanisms.
A microbenchmark result is in the subsequent bpf patch.
Let's allow opt-out from the per-protocol memory accounting if
sk->sk_bypass_prot_mem is true.
sk->sk_bypass_prot_mem and sk->sk_prot are placed in the same cache
line, and sk_has_account() always fetches sk->sk_prot before accessing
sk->sk_bypass_prot_mem, so there is no extra cache miss for this patch.
The following patches will set sk->sk_bypass_prot_mem to true, and
then, the per-protocol memory accounting will be skipped.
Note that this does NOT disable memcg, but rather the per-protocol one.
Another option not to use the hole in struct sock_common is create
sk_prot variants like tcp_prot_bypass, but this would complicate
SOCKMAP logic, tcp_bpf_prots etc.
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
Reviewed-by: Shakeel Butt <shakeel.butt@linux.dev>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Acked-by: Roman Gushchin <roman.gushchin@linux.dev>
Link: https://patch.msgid.link/20251014235604.3057003-3-kuniyu@google.com
2025-10-14 23:54:55 +00:00
|
|
|
|
2020-11-16 10:48:10 +01:00
|
|
|
|
2023-10-23 13:44:42 -07:00
|
|
|
|
2020-11-27 11:10:25 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-03-27 14:48:43 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-16 10:48:10 +01:00
|
|
|
|
2020-03-27 14:48:43 -07:00
|
|
|
|
2026-04-03 13:29:28 +02:00
|
|
|
|
2020-03-27 14:48:43 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-16 10:48:06 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-16 10:48:10 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-09-01 10:15:36 -07:00
|
|
|
|
2020-11-16 10:48:06 +01:00
|
|
|
|
|
|
|
|
|
2026-02-03 19:41:22 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-16 10:48:13 +01:00
|
|
|
|
|
|
|
|
|
2022-05-04 14:54:04 -07:00
|
|
|
|
2020-11-16 10:48:13 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-05-04 14:54:04 -07:00
|
|
|
|
2026-02-03 19:41:22 +01:00
|
|
|
|
2020-11-16 10:48:13 +01:00
|
|
|
|
2022-05-04 14:54:05 -07:00
|
|
|
|
2022-05-04 14:54:04 -07:00
|
|
|
|
2022-05-04 14:54:05 -07:00
|
|
|
|
|
|
|
|
|
2020-11-16 10:48:13 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-27 11:10:25 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-27 11:10:27 +01:00
|
|
|
|
2020-11-27 11:10:25 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-27 11:10:27 +01:00
|
|
|
|
2020-11-27 11:10:25 +01:00
|
|
|
|
2020-11-27 11:10:27 +01:00
|
|
|
|
2020-11-27 11:10:25 +01:00
|
|
|
|
2021-10-27 13:19:21 -07:00
|
|
|
|
2021-09-22 19:26:41 +02:00
|
|
|
|
2020-11-27 11:10:25 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-09-22 19:26:41 +02:00
|
|
|
|
2020-11-27 11:10:25 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-27 11:10:27 +01:00
|
|
|
|
2020-11-27 11:10:25 +01:00
|
|
|
|
2021-09-22 19:26:41 +02:00
|
|
|
|
2020-11-27 11:10:25 +01:00
|
|
|
|
|
|
|
|
|
2021-09-22 19:26:41 +02:00
|
|
|
|
|
|
|
|
|
2020-11-27 11:10:25 +01:00
|
|
|
|
2022-03-17 15:09:53 -07:00
|
|
|
|
2020-11-27 11:10:25 +01:00
|
|
|
|
2021-09-22 19:26:41 +02:00
|
|
|
|
2020-11-27 11:10:25 +01:00
|
|
|
|
|
|
|
|
|
2021-09-22 19:26:41 +02:00
|
|
|
|
2020-11-27 11:10:25 +01:00
|
|
|
|
2021-09-01 10:15:36 -07:00
|
|
|
|
2020-11-27 11:10:25 +01:00
|
|
|
|
2021-09-01 10:15:36 -07:00
|
|
|
|
2020-11-27 11:10:25 +01:00
|
|
|
|
|
|
|
|
|
2021-06-17 16:46:08 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-04-22 14:55:39 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-07-23 16:32:23 +02:00
|
|
|
|
|
|
|
|
|
2025-07-14 18:41:44 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-04-22 14:55:39 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-11-14 00:16:13 +01:00
|
|
|
|
|
|
|
|
|
2020-01-21 16:56:27 -08:00
|
|
|
|
2020-11-16 10:48:10 +01:00
|
|
|
|
2020-11-16 10:48:06 +01:00
|
|
|
|
2020-01-21 16:56:27 -08:00
|
|
|
|
2020-11-16 10:48:10 +01:00
|
|
|
|
2021-09-22 19:26:41 +02:00
|
|
|
|
2020-01-21 16:56:23 -08:00
|
|
|
|
2020-11-16 10:48:13 +01:00
|
|
|
|
2020-01-21 16:56:23 -08:00
|
|
|
|
2021-09-22 19:26:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-01-21 16:56:23 -08:00
|
|
|
|
mptcp: pr_debug: add missing \n at the end
pr_debug() have been added in various places in MPTCP code to help
developers to debug some situations. With the dynamic debug feature, it
is easy to enable all or some of them, and asks users to reproduce
issues with extra debug.
Many of these pr_debug() don't end with a new line, while no 'pr_cont()'
are used in MPTCP code. So the goal was not to display multiple debug
messages on one line: they were then not missing the '\n' on purpose.
Not having the new line at the end causes these messages to be printed
with a delay, when something else needs to be printed. This issue is not
visible when many messages need to be printed, but it is annoying and
confusing when only specific messages are expected, e.g.
# echo "func mptcp_pm_add_addr_echoed +fmp" \
> /sys/kernel/debug/dynamic_debug/control
# ./mptcp_join.sh "signal address"; \
echo "$(awk '{print $1}' /proc/uptime) - end"; \
sleep 5s; \
echo "$(awk '{print $1}' /proc/uptime) - restart"; \
./mptcp_join.sh "signal address"
013 signal address
(...)
10.75 - end
15.76 - restart
013 signal address
[ 10.367935] mptcp:mptcp_pm_add_addr_echoed: MPTCP: msk=(...)
(...)
=> a delay of 5 seconds: printed with a 10.36 ts, but after 'restart'
which was printed at the 15.76 ts.
The 'Fixes' tag here below points to the first pr_debug() used without
'\n' in net/mptcp. This patch could be split in many small ones, with
different Fixes tag, but it doesn't seem worth it, because it is easy to
re-generate this patch with this simple 'sed' command:
git grep -l pr_debug -- net/mptcp |
xargs sed -i "s/\(pr_debug(\".*[^n]\)\(\"[,)]\)/\1\\\n\2/g"
So in case of conflicts, simply drop the modifications, and launch this
command.
Fixes: f870fa0b5768 ("mptcp: Add MPTCP socket stubs")
Cc: stable@vger.kernel.org
Reviewed-by: Geliang Tang <geliang@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20240826-net-mptcp-close-extra-sf-fin-v1-4-905199fe1172@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26 19:11:21 +02:00
|
|
|
|
2020-11-16 10:48:10 +01:00
|
|
|
|
2020-01-21 16:56:23 -08:00
|
|
|
|
2021-09-22 19:26:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-08-04 17:21:26 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-16 10:48:10 +01:00
|
|
|
|
2023-11-14 00:16:13 +01:00
|
|
|
|
|
|
|
|
|
2020-11-16 10:48:10 +01:00
|
|
|
|
2021-09-22 19:26:41 +02:00
|
|
|
|
|
|
|
|
|
2020-01-21 16:56:27 -08:00
|
|
|
|
2021-09-22 19:26:41 +02:00
|
|
|
|
2020-01-21 16:56:27 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-10-25 16:37:07 -07:00
|
|
|
|
2021-09-01 10:15:36 -07:00
|
|
|
|
2020-01-21 16:56:27 -08:00
|
|
|
|
2024-02-23 17:14:14 +01:00
|
|
|
|
2021-09-01 10:15:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-09-22 19:26:41 +02:00
|
|
|
|
|
|
|
|
|
2024-04-29 13:40:21 +00:00
|
|
|
|
2021-09-22 19:26:41 +02:00
|
|
|
|
|
|
|
|
|
2020-12-10 14:25:06 -08:00
|
|
|
|
2020-03-27 14:48:43 -07:00
|
|
|
|
2021-09-22 19:26:41 +02:00
|
|
|
|
|
|
|
|
|
2021-09-01 10:15:36 -07:00
|
|
|
|
2021-09-22 19:26:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-10-25 16:37:07 -07:00
|
|
|
|
2021-09-22 19:26:41 +02:00
|
|
|
|
2021-09-01 10:15:36 -07:00
|
|
|
|
2020-11-16 10:48:13 +01:00
|
|
|
|
2022-05-04 14:54:04 -07:00
|
|
|
|
2021-09-22 19:26:41 +02:00
|
|
|
|
2020-11-27 11:10:26 +01:00
|
|
|
|
|
|
|
|
|
2025-10-28 09:16:54 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-10-27 13:19:18 -07:00
|
|
|
|
2020-11-16 10:48:13 +01:00
|
|
|
|
2021-09-22 19:26:41 +02:00
|
|
|
|
|
|
|
|
|
2020-11-16 10:48:13 +01:00
|
|
|
|
2020-11-27 11:10:26 +01:00
|
|
|
|
2021-09-22 19:26:41 +02:00
|
|
|
|
2020-11-16 10:48:13 +01:00
|
|
|
|
|
|
|
|
|
2021-09-22 19:26:41 +02:00
|
|
|
|
|
|
|
|
|
2021-10-27 13:19:18 -07:00
|
|
|
|
2020-11-16 10:48:03 +01:00
|
|
|
|
2020-08-14 15:56:34 +02:00
|
|
|
|
2020-03-27 14:48:43 -07:00
|
|
|
|
2021-09-22 19:26:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-01-21 16:56:27 -08:00
|
|
|
|
|
|
|
|
|
2021-09-22 19:26:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-27 11:10:25 +01:00
|
|
|
|
2020-01-21 16:56:23 -08:00
|
|
|
|
|
|
|
|
|
2020-11-16 10:48:10 +01:00
|
|
|
|
2020-01-21 16:56:23 -08:00
|
|
|
|
2021-09-22 19:26:41 +02:00
|
|
|
|
2020-01-21 16:56:23 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
mptcp: pr_debug: add missing \n at the end
pr_debug() have been added in various places in MPTCP code to help
developers to debug some situations. With the dynamic debug feature, it
is easy to enable all or some of them, and asks users to reproduce
issues with extra debug.
Many of these pr_debug() don't end with a new line, while no 'pr_cont()'
are used in MPTCP code. So the goal was not to display multiple debug
messages on one line: they were then not missing the '\n' on purpose.
Not having the new line at the end causes these messages to be printed
with a delay, when something else needs to be printed. This issue is not
visible when many messages need to be printed, but it is annoying and
confusing when only specific messages are expected, e.g.
# echo "func mptcp_pm_add_addr_echoed +fmp" \
> /sys/kernel/debug/dynamic_debug/control
# ./mptcp_join.sh "signal address"; \
echo "$(awk '{print $1}' /proc/uptime) - end"; \
sleep 5s; \
echo "$(awk '{print $1}' /proc/uptime) - restart"; \
./mptcp_join.sh "signal address"
013 signal address
(...)
10.75 - end
15.76 - restart
013 signal address
[ 10.367935] mptcp:mptcp_pm_add_addr_echoed: MPTCP: msk=(...)
(...)
=> a delay of 5 seconds: printed with a 10.36 ts, but after 'restart'
which was printed at the 15.76 ts.
The 'Fixes' tag here below points to the first pr_debug() used without
'\n' in net/mptcp. This patch could be split in many small ones, with
different Fixes tag, but it doesn't seem worth it, because it is easy to
re-generate this patch with this simple 'sed' command:
git grep -l pr_debug -- net/mptcp |
xargs sed -i "s/\(pr_debug(\".*[^n]\)\(\"[,)]\)/\1\\\n\2/g"
So in case of conflicts, simply drop the modifications, and launch this
command.
Fixes: f870fa0b5768 ("mptcp: Add MPTCP socket stubs")
Cc: stable@vger.kernel.org
Reviewed-by: Geliang Tang <geliang@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20240826-net-mptcp-close-extra-sf-fin-v1-4-905199fe1172@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26 19:11:21 +02:00
|
|
|
|
2020-01-21 16:56:23 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-16 10:48:13 +01:00
|
|
|
|
2025-10-28 09:16:55 +01:00
|
|
|
|
2021-09-22 19:26:41 +02:00
|
|
|
|
2020-11-16 10:48:13 +01:00
|
|
|
|
2021-06-17 16:46:08 -07:00
|
|
|
|
2021-09-22 19:26:41 +02:00
|
|
|
|
2020-11-16 10:48:13 +01:00
|
|
|
|
2021-06-17 16:46:08 -07:00
|
|
|
|
2020-11-16 10:48:13 +01:00
|
|
|
|
2020-01-21 16:56:27 -08:00
|
|
|
|
2021-06-17 16:46:08 -07:00
|
|
|
|
2021-09-22 19:26:41 +02:00
|
|
|
|
2022-04-22 14:55:39 -07:00
|
|
|
|
|
|
|
|
|
2022-03-07 12:44:31 -08:00
|
|
|
|
2021-09-22 19:26:41 +02:00
|
|
|
|
2026-04-03 13:29:28 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-09-22 19:26:41 +02:00
|
|
|
|
2020-01-21 16:56:23 -08:00
|
|
|
|
|
|
|
|
|
2020-09-14 10:01:17 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-12-17 15:37:00 -08:00
|
|
|
|
2020-09-14 10:01:17 +02:00
|
|
|
|
|
|
|
|
|
2021-08-13 15:15:45 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-08-13 15:15:46 -07:00
|
|
|
|
2021-08-13 15:15:45 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-12-17 15:37:00 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-08-13 15:15:41 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-08-21 15:25:18 -07:00
|
|
|
|
2020-03-27 14:48:39 -07:00
|
|
|
|
2021-12-17 15:37:00 -08:00
|
|
|
|
2020-03-27 14:48:39 -07:00
|
|
|
|
2021-08-13 15:15:41 -07:00
|
|
|
|
2021-12-17 15:37:00 -08:00
|
|
|
|
2020-09-14 10:01:17 +02:00
|
|
|
|
|
|
|
|
|
2021-12-17 15:37:00 -08:00
|
|
|
|
2021-08-13 15:15:41 -07:00
|
|
|
|
2020-03-27 14:48:39 -07:00
|
|
|
|
2020-09-14 10:01:17 +02:00
|
|
|
|
2021-12-17 15:37:00 -08:00
|
|
|
|
2020-09-14 10:01:17 +02:00
|
|
|
|
2021-12-17 15:37:00 -08:00
|
|
|
|
2020-09-14 10:01:17 +02:00
|
|
|
|
2021-12-17 15:37:00 -08:00
|
|
|
|
2020-09-14 10:01:17 +02:00
|
|
|
|
2024-07-27 12:01:23 +02:00
|
|
|
|
|
|
|
|
|
2021-04-16 15:38:04 -07:00
|
|
|
|
2020-09-14 10:01:17 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-08-13 15:15:41 -07:00
|
|
|
|
2024-07-27 12:01:23 +02:00
|
|
|
|
2021-12-17 15:37:00 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-14 10:01:17 +02:00
|
|
|
|
2021-12-17 15:37:00 -08:00
|
|
|
|
2024-07-27 12:01:23 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-14 10:01:17 +02:00
|
|
|
|
|
|
|
|
|
2021-08-13 15:15:41 -07:00
|
|
|
|
2020-09-14 10:01:17 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-12-17 15:37:00 -08:00
|
|
|
|
2020-09-14 10:01:17 +02:00
|
|
|
|
2021-12-17 15:37:00 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-07-19 00:06:59 +02:00
|
|
|
|
2021-12-17 15:37:00 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-05-04 14:54:04 -07:00
|
|
|
|
2021-12-17 15:37:00 -08:00
|
|
|
|
2021-01-20 15:39:11 +01:00
|
|
|
|
2026-02-03 19:41:22 +01:00
|
|
|
|
2021-12-17 15:37:00 -08:00
|
|
|
|
2023-08-21 15:25:13 -07:00
|
|
|
|
2022-05-04 14:54:04 -07:00
|
|
|
|
|
|
|
|
|
2021-12-17 15:37:00 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-03-27 14:48:39 -07:00
|
|
|
|
|
|
|
|
|
2021-10-26 16:29:16 -07:00
|
|
|
|
2020-11-16 10:48:10 +01:00
|
|
|
|
2026-09-17 15:05:58 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-16 10:48:10 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-09-24 14:12:34 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-06-20 18:30:15 +02:00
|
|
|
|
|
|
|
|
|
2024-02-02 12:40:08 +01:00
|
|
|
|
2023-06-20 18:30:15 +02:00
|
|
|
|
2021-09-24 14:12:34 -07:00
|
|
|
|
|
|
|
|
|
2021-12-03 14:35:40 -08:00
|
|
|
|
2021-09-24 14:12:38 -07:00
|
|
|
|
2024-02-08 19:03:49 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-09-24 14:12:38 -07:00
|
|
|
|
|
|
|
|
|
mptcp: refactor push_pending logic
To support redundant package schedulers more easily, this patch refactors
__mptcp_push_pending() logic from:
For each dfrag:
While sends succeed:
Call the scheduler (selects subflow and msk->snd_burst)
Update subflow locks (push/release/acquire as needed)
Send the dfrag data with mptcp_sendmsg_frag()
Update already_sent, snd_nxt, snd_burst
Update msk->first_pending
Push/release on final subflow
->
While first_pending isn't empty:
Call the scheduler (selects subflow and msk->snd_burst)
Update subflow locks (push/release/acquire as needed)
For each pending dfrag:
While sends succeed:
Send the dfrag data with mptcp_sendmsg_frag()
Update already_sent, snd_nxt, snd_burst
Update msk->first_pending
Break if required by msk->snd_burst / etc
Push/release on final subflow
Refactors __mptcp_subflow_push_pending logic from:
For each dfrag:
While sends succeed:
Call the scheduler (selects subflow and msk->snd_burst)
Send the dfrag data with mptcp_subflow_delegate(), break
Send the dfrag data with mptcp_sendmsg_frag()
Update dfrag->already_sent, msk->snd_nxt, msk->snd_burst
Update msk->first_pending
->
While first_pending isn't empty:
Call the scheduler (selects subflow and msk->snd_burst)
Send the dfrag data with mptcp_subflow_delegate(), break
Send the dfrag data with mptcp_sendmsg_frag()
For each pending dfrag:
While sends succeed:
Send the dfrag data with mptcp_sendmsg_frag()
Update already_sent, snd_nxt, snd_burst
Update msk->first_pending
Break if required by msk->snd_burst / etc
Move the duplicate code from __mptcp_push_pending() and
__mptcp_subflow_push_pending() into a new helper function, named
__subflow_push_pending(). Simplify __mptcp_push_pending() and
__mptcp_subflow_push_pending() by invoking this helper.
Also move the burst check conditions out of the function
mptcp_subflow_get_send(), check them in __subflow_push_pending() in
the inner "for each pending dfrag" loop.
Reviewed-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: Geliang Tang <geliang.tang@suse.com>
Signed-off-by: Mat Martineau <martineau@kernel.org>
Link: https://lore.kernel.org/r/20230821-upstream-net-next-20230818-v1-1-0c860fb256a8@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-08-21 15:25:12 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-10-28 09:16:52 +01:00
|
|
|
|
mptcp: refactor push_pending logic
To support redundant package schedulers more easily, this patch refactors
__mptcp_push_pending() logic from:
For each dfrag:
While sends succeed:
Call the scheduler (selects subflow and msk->snd_burst)
Update subflow locks (push/release/acquire as needed)
Send the dfrag data with mptcp_sendmsg_frag()
Update already_sent, snd_nxt, snd_burst
Update msk->first_pending
Push/release on final subflow
->
While first_pending isn't empty:
Call the scheduler (selects subflow and msk->snd_burst)
Update subflow locks (push/release/acquire as needed)
For each pending dfrag:
While sends succeed:
Send the dfrag data with mptcp_sendmsg_frag()
Update already_sent, snd_nxt, snd_burst
Update msk->first_pending
Break if required by msk->snd_burst / etc
Push/release on final subflow
Refactors __mptcp_subflow_push_pending logic from:
For each dfrag:
While sends succeed:
Call the scheduler (selects subflow and msk->snd_burst)
Send the dfrag data with mptcp_subflow_delegate(), break
Send the dfrag data with mptcp_sendmsg_frag()
Update dfrag->already_sent, msk->snd_nxt, msk->snd_burst
Update msk->first_pending
->
While first_pending isn't empty:
Call the scheduler (selects subflow and msk->snd_burst)
Send the dfrag data with mptcp_subflow_delegate(), break
Send the dfrag data with mptcp_sendmsg_frag()
For each pending dfrag:
While sends succeed:
Send the dfrag data with mptcp_sendmsg_frag()
Update already_sent, snd_nxt, snd_burst
Update msk->first_pending
Break if required by msk->snd_burst / etc
Move the duplicate code from __mptcp_push_pending() and
__mptcp_subflow_push_pending() into a new helper function, named
__subflow_push_pending(). Simplify __mptcp_push_pending() and
__mptcp_subflow_push_pending() by invoking this helper.
Also move the burst check conditions out of the function
mptcp_subflow_get_send(), check them in __subflow_push_pending() in
the inner "for each pending dfrag" loop.
Reviewed-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: Geliang Tang <geliang.tang@suse.com>
Signed-off-by: Mat Martineau <martineau@kernel.org>
Link: https://lore.kernel.org/r/20230821-upstream-net-next-20230818-v1-1-0c860fb256a8@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-08-21 15:25:12 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
mptcp: add last time fields in mptcp_info
This patch adds "last time" fields last_data_sent, last_data_recv and
last_ack_recv in struct mptcp_sock to record the last time data_sent,
data_recv and ack_recv happened. They all are initialized as
tcp_jiffies32 in __mptcp_init_sock(), and updated as tcp_jiffies32 too
when data is sent in __subflow_push_pending(), data is received in
__mptcp_move_skbs_from_subflow(), and ack is received in ack_update_msk().
Similar to tcpi_last_data_sent, tcpi_last_data_recv and tcpi_last_ack_recv
exposed with TCP, this patch exposes the last time "an action happened" for
MPTCP in mptcp_info, named mptcpi_last_data_sent, mptcpi_last_data_recv and
mptcpi_last_ack_recv, calculated in mptcp_diag_fill_info() as the time
deltas between now and the newly added last time fields in mptcp_sock.
Since msk->last_ack_recv needs to be protected by mptcp_data_lock/unlock,
and lock_sock_fast can sleep and be quite slow, move the entire
mptcp_data_lock/unlock block after the lock/unlock_sock_fast block.
Then mptcpi_last_data_sent and mptcpi_last_data_recv are set in
lock/unlock_sock_fast block, while mptcpi_last_ack_recv is set in
mptcp_data_lock/unlock block, which is protected by a spinlock and
should not block for too long.
Also add three reserved bytes in struct mptcp_info not to have holes in
this structure exposed to userspace.
Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/446
Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn>
Reviewed-by: Mat Martineau <martineau@kernel.org>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://lore.kernel.org/r/20240410-upstream-net-next-20240405-mptcp-last-time-info-v2-1-f95bd6b33e51@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-04-10 11:48:24 +02:00
|
|
|
|
|
|
|
|
|
mptcp: refactor push_pending logic
To support redundant package schedulers more easily, this patch refactors
__mptcp_push_pending() logic from:
For each dfrag:
While sends succeed:
Call the scheduler (selects subflow and msk->snd_burst)
Update subflow locks (push/release/acquire as needed)
Send the dfrag data with mptcp_sendmsg_frag()
Update already_sent, snd_nxt, snd_burst
Update msk->first_pending
Push/release on final subflow
->
While first_pending isn't empty:
Call the scheduler (selects subflow and msk->snd_burst)
Update subflow locks (push/release/acquire as needed)
For each pending dfrag:
While sends succeed:
Send the dfrag data with mptcp_sendmsg_frag()
Update already_sent, snd_nxt, snd_burst
Update msk->first_pending
Break if required by msk->snd_burst / etc
Push/release on final subflow
Refactors __mptcp_subflow_push_pending logic from:
For each dfrag:
While sends succeed:
Call the scheduler (selects subflow and msk->snd_burst)
Send the dfrag data with mptcp_subflow_delegate(), break
Send the dfrag data with mptcp_sendmsg_frag()
Update dfrag->already_sent, msk->snd_nxt, msk->snd_burst
Update msk->first_pending
->
While first_pending isn't empty:
Call the scheduler (selects subflow and msk->snd_burst)
Send the dfrag data with mptcp_subflow_delegate(), break
Send the dfrag data with mptcp_sendmsg_frag()
For each pending dfrag:
While sends succeed:
Send the dfrag data with mptcp_sendmsg_frag()
Update already_sent, snd_nxt, snd_burst
Update msk->first_pending
Break if required by msk->snd_burst / etc
Move the duplicate code from __mptcp_push_pending() and
__mptcp_subflow_push_pending() into a new helper function, named
__subflow_push_pending(). Simplify __mptcp_push_pending() and
__mptcp_subflow_push_pending() by invoking this helper.
Also move the burst check conditions out of the function
mptcp_subflow_get_send(), check them in __subflow_push_pending() in
the inner "for each pending dfrag" loop.
Reviewed-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: Geliang Tang <geliang.tang@suse.com>
Signed-off-by: Mat Martineau <martineau@kernel.org>
Link: https://lore.kernel.org/r/20230821-upstream-net-next-20230818-v1-1-0c860fb256a8@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-08-21 15:25:12 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-08-13 15:15:45 -07:00
|
|
|
|
2020-11-16 10:48:10 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-12-05 19:55:16 +01:00
|
|
|
|
2023-08-21 15:25:19 -07:00
|
|
|
|
2020-11-16 10:48:10 +01:00
|
|
|
|
2023-08-21 15:25:19 -07:00
|
|
|
|
|
|
|
|
|
mptcp: refactor push_pending logic
To support redundant package schedulers more easily, this patch refactors
__mptcp_push_pending() logic from:
For each dfrag:
While sends succeed:
Call the scheduler (selects subflow and msk->snd_burst)
Update subflow locks (push/release/acquire as needed)
Send the dfrag data with mptcp_sendmsg_frag()
Update already_sent, snd_nxt, snd_burst
Update msk->first_pending
Push/release on final subflow
->
While first_pending isn't empty:
Call the scheduler (selects subflow and msk->snd_burst)
Update subflow locks (push/release/acquire as needed)
For each pending dfrag:
While sends succeed:
Send the dfrag data with mptcp_sendmsg_frag()
Update already_sent, snd_nxt, snd_burst
Update msk->first_pending
Break if required by msk->snd_burst / etc
Push/release on final subflow
Refactors __mptcp_subflow_push_pending logic from:
For each dfrag:
While sends succeed:
Call the scheduler (selects subflow and msk->snd_burst)
Send the dfrag data with mptcp_subflow_delegate(), break
Send the dfrag data with mptcp_sendmsg_frag()
Update dfrag->already_sent, msk->snd_nxt, msk->snd_burst
Update msk->first_pending
->
While first_pending isn't empty:
Call the scheduler (selects subflow and msk->snd_burst)
Send the dfrag data with mptcp_subflow_delegate(), break
Send the dfrag data with mptcp_sendmsg_frag()
For each pending dfrag:
While sends succeed:
Send the dfrag data with mptcp_sendmsg_frag()
Update already_sent, snd_nxt, snd_burst
Update msk->first_pending
Break if required by msk->snd_burst / etc
Move the duplicate code from __mptcp_push_pending() and
__mptcp_subflow_push_pending() into a new helper function, named
__subflow_push_pending(). Simplify __mptcp_push_pending() and
__mptcp_subflow_push_pending() by invoking this helper.
Also move the burst check conditions out of the function
mptcp_subflow_get_send(), check them in __subflow_push_pending() in
the inner "for each pending dfrag" loop.
Reviewed-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: Geliang Tang <geliang.tang@suse.com>
Signed-off-by: Mat Martineau <martineau@kernel.org>
Link: https://lore.kernel.org/r/20230821-upstream-net-next-20230818-v1-1-0c860fb256a8@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-08-21 15:25:12 -07:00
|
|
|
|
2020-11-16 10:48:10 +01:00
|
|
|
|
2023-08-21 15:25:19 -07:00
|
|
|
|
|
|
|
|
|
2020-11-16 10:48:10 +01:00
|
|
|
|
2023-08-21 15:25:19 -07:00
|
|
|
|
2020-11-16 10:48:10 +01:00
|
|
|
|
2023-08-21 15:25:19 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-16 10:48:10 +01:00
|
|
|
|
2023-08-21 15:25:19 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-12-05 19:55:16 +01:00
|
|
|
|
2023-08-21 15:25:19 -07:00
|
|
|
|
2020-11-16 10:48:10 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-10-26 16:29:16 -07:00
|
|
|
|
2020-11-16 10:48:10 +01:00
|
|
|
|
2025-12-05 19:55:16 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-06-20 18:24:21 +02:00
|
|
|
|
2025-12-05 19:55:16 +01:00
|
|
|
|
2020-11-16 10:48:10 +01:00
|
|
|
|
|
|
|
|
|
2022-11-10 15:23:19 -08:00
|
|
|
|
2020-11-27 11:10:27 +01:00
|
|
|
|
|
|
|
|
|
2021-09-01 10:15:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-08-21 15:25:19 -07:00
|
|
|
|
2021-01-20 15:39:14 +01:00
|
|
|
|
mptcp: refactor push_pending logic
To support redundant package schedulers more easily, this patch refactors
__mptcp_push_pending() logic from:
For each dfrag:
While sends succeed:
Call the scheduler (selects subflow and msk->snd_burst)
Update subflow locks (push/release/acquire as needed)
Send the dfrag data with mptcp_sendmsg_frag()
Update already_sent, snd_nxt, snd_burst
Update msk->first_pending
Push/release on final subflow
->
While first_pending isn't empty:
Call the scheduler (selects subflow and msk->snd_burst)
Update subflow locks (push/release/acquire as needed)
For each pending dfrag:
While sends succeed:
Send the dfrag data with mptcp_sendmsg_frag()
Update already_sent, snd_nxt, snd_burst
Update msk->first_pending
Break if required by msk->snd_burst / etc
Push/release on final subflow
Refactors __mptcp_subflow_push_pending logic from:
For each dfrag:
While sends succeed:
Call the scheduler (selects subflow and msk->snd_burst)
Send the dfrag data with mptcp_subflow_delegate(), break
Send the dfrag data with mptcp_sendmsg_frag()
Update dfrag->already_sent, msk->snd_nxt, msk->snd_burst
Update msk->first_pending
->
While first_pending isn't empty:
Call the scheduler (selects subflow and msk->snd_burst)
Send the dfrag data with mptcp_subflow_delegate(), break
Send the dfrag data with mptcp_sendmsg_frag()
For each pending dfrag:
While sends succeed:
Send the dfrag data with mptcp_sendmsg_frag()
Update already_sent, snd_nxt, snd_burst
Update msk->first_pending
Break if required by msk->snd_burst / etc
Move the duplicate code from __mptcp_push_pending() and
__mptcp_subflow_push_pending() into a new helper function, named
__subflow_push_pending(). Simplify __mptcp_push_pending() and
__mptcp_subflow_push_pending() by invoking this helper.
Also move the burst check conditions out of the function
mptcp_subflow_get_send(), check them in __subflow_push_pending() in
the inner "for each pending dfrag" loop.
Reviewed-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: Geliang Tang <geliang.tang@suse.com>
Signed-off-by: Mat Martineau <martineau@kernel.org>
Link: https://lore.kernel.org/r/20230821-upstream-net-next-20230818-v1-1-0c860fb256a8@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-08-21 15:25:12 -07:00
|
|
|
|
2020-11-27 11:10:27 +01:00
|
|
|
|
|
|
|
|
|
2023-08-21 15:25:19 -07:00
|
|
|
|
|
|
|
|
|
mptcp: refactor push_pending logic
To support redundant package schedulers more easily, this patch refactors
__mptcp_push_pending() logic from:
For each dfrag:
While sends succeed:
Call the scheduler (selects subflow and msk->snd_burst)
Update subflow locks (push/release/acquire as needed)
Send the dfrag data with mptcp_sendmsg_frag()
Update already_sent, snd_nxt, snd_burst
Update msk->first_pending
Push/release on final subflow
->
While first_pending isn't empty:
Call the scheduler (selects subflow and msk->snd_burst)
Update subflow locks (push/release/acquire as needed)
For each pending dfrag:
While sends succeed:
Send the dfrag data with mptcp_sendmsg_frag()
Update already_sent, snd_nxt, snd_burst
Update msk->first_pending
Break if required by msk->snd_burst / etc
Push/release on final subflow
Refactors __mptcp_subflow_push_pending logic from:
For each dfrag:
While sends succeed:
Call the scheduler (selects subflow and msk->snd_burst)
Send the dfrag data with mptcp_subflow_delegate(), break
Send the dfrag data with mptcp_sendmsg_frag()
Update dfrag->already_sent, msk->snd_nxt, msk->snd_burst
Update msk->first_pending
->
While first_pending isn't empty:
Call the scheduler (selects subflow and msk->snd_burst)
Send the dfrag data with mptcp_subflow_delegate(), break
Send the dfrag data with mptcp_sendmsg_frag()
For each pending dfrag:
While sends succeed:
Send the dfrag data with mptcp_sendmsg_frag()
Update already_sent, snd_nxt, snd_burst
Update msk->first_pending
Break if required by msk->snd_burst / etc
Move the duplicate code from __mptcp_push_pending() and
__mptcp_subflow_push_pending() into a new helper function, named
__subflow_push_pending(). Simplify __mptcp_push_pending() and
__mptcp_subflow_push_pending() by invoking this helper.
Also move the burst check conditions out of the function
mptcp_subflow_get_send(), check them in __subflow_push_pending() in
the inner "for each pending dfrag" loop.
Reviewed-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: Geliang Tang <geliang.tang@suse.com>
Signed-off-by: Mat Martineau <martineau@kernel.org>
Link: https://lore.kernel.org/r/20230821-upstream-net-next-20230818-v1-1-0c860fb256a8@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-08-21 15:25:12 -07:00
|
|
|
|
2020-11-27 11:10:27 +01:00
|
|
|
|
mptcp: refactor push_pending logic
To support redundant package schedulers more easily, this patch refactors
__mptcp_push_pending() logic from:
For each dfrag:
While sends succeed:
Call the scheduler (selects subflow and msk->snd_burst)
Update subflow locks (push/release/acquire as needed)
Send the dfrag data with mptcp_sendmsg_frag()
Update already_sent, snd_nxt, snd_burst
Update msk->first_pending
Push/release on final subflow
->
While first_pending isn't empty:
Call the scheduler (selects subflow and msk->snd_burst)
Update subflow locks (push/release/acquire as needed)
For each pending dfrag:
While sends succeed:
Send the dfrag data with mptcp_sendmsg_frag()
Update already_sent, snd_nxt, snd_burst
Update msk->first_pending
Break if required by msk->snd_burst / etc
Push/release on final subflow
Refactors __mptcp_subflow_push_pending logic from:
For each dfrag:
While sends succeed:
Call the scheduler (selects subflow and msk->snd_burst)
Send the dfrag data with mptcp_subflow_delegate(), break
Send the dfrag data with mptcp_sendmsg_frag()
Update dfrag->already_sent, msk->snd_nxt, msk->snd_burst
Update msk->first_pending
->
While first_pending isn't empty:
Call the scheduler (selects subflow and msk->snd_burst)
Send the dfrag data with mptcp_subflow_delegate(), break
Send the dfrag data with mptcp_sendmsg_frag()
For each pending dfrag:
While sends succeed:
Send the dfrag data with mptcp_sendmsg_frag()
Update already_sent, snd_nxt, snd_burst
Update msk->first_pending
Break if required by msk->snd_burst / etc
Move the duplicate code from __mptcp_push_pending() and
__mptcp_subflow_push_pending() into a new helper function, named
__subflow_push_pending(). Simplify __mptcp_push_pending() and
__mptcp_subflow_push_pending() by invoking this helper.
Also move the burst check conditions out of the function
mptcp_subflow_get_send(), check them in __subflow_push_pending() in
the inner "for each pending dfrag" loop.
Reviewed-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: Geliang Tang <geliang.tang@suse.com>
Signed-off-by: Mat Martineau <martineau@kernel.org>
Link: https://lore.kernel.org/r/20230821-upstream-net-next-20230818-v1-1-0c860fb256a8@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-08-21 15:25:12 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-08-21 15:25:19 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-27 11:10:27 +01:00
|
|
|
|
mptcp: refactor push_pending logic
To support redundant package schedulers more easily, this patch refactors
__mptcp_push_pending() logic from:
For each dfrag:
While sends succeed:
Call the scheduler (selects subflow and msk->snd_burst)
Update subflow locks (push/release/acquire as needed)
Send the dfrag data with mptcp_sendmsg_frag()
Update already_sent, snd_nxt, snd_burst
Update msk->first_pending
Push/release on final subflow
->
While first_pending isn't empty:
Call the scheduler (selects subflow and msk->snd_burst)
Update subflow locks (push/release/acquire as needed)
For each pending dfrag:
While sends succeed:
Send the dfrag data with mptcp_sendmsg_frag()
Update already_sent, snd_nxt, snd_burst
Update msk->first_pending
Break if required by msk->snd_burst / etc
Push/release on final subflow
Refactors __mptcp_subflow_push_pending logic from:
For each dfrag:
While sends succeed:
Call the scheduler (selects subflow and msk->snd_burst)
Send the dfrag data with mptcp_subflow_delegate(), break
Send the dfrag data with mptcp_sendmsg_frag()
Update dfrag->already_sent, msk->snd_nxt, msk->snd_burst
Update msk->first_pending
->
While first_pending isn't empty:
Call the scheduler (selects subflow and msk->snd_burst)
Send the dfrag data with mptcp_subflow_delegate(), break
Send the dfrag data with mptcp_sendmsg_frag()
For each pending dfrag:
While sends succeed:
Send the dfrag data with mptcp_sendmsg_frag()
Update already_sent, snd_nxt, snd_burst
Update msk->first_pending
Break if required by msk->snd_burst / etc
Move the duplicate code from __mptcp_push_pending() and
__mptcp_subflow_push_pending() into a new helper function, named
__subflow_push_pending(). Simplify __mptcp_push_pending() and
__mptcp_subflow_push_pending() by invoking this helper.
Also move the burst check conditions out of the function
mptcp_subflow_get_send(), check them in __subflow_push_pending() in
the inner "for each pending dfrag" loop.
Reviewed-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: Geliang Tang <geliang.tang@suse.com>
Signed-off-by: Mat Martineau <martineau@kernel.org>
Link: https://lore.kernel.org/r/20230821-upstream-net-next-20230818-v1-1-0c860fb256a8@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-08-21 15:25:12 -07:00
|
|
|
|
2023-08-21 15:25:19 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-09-17 15:05:59 +02:00
|
|
|
|
|
|
|
|
|
2023-08-21 15:25:19 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-27 11:10:27 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-09-16 12:52:48 +02:00
|
|
|
|
|
|
|
|
|
2021-02-11 15:30:42 -08:00
|
|
|
|
2020-11-27 11:10:27 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-12-20 11:52:14 -08:00
|
|
|
|
|
|
|
|
|
2023-04-14 16:08:02 +02:00
|
|
|
|
2022-10-21 15:58:56 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-04-14 16:08:02 +02:00
|
|
|
|
2022-10-21 15:58:56 -07:00
|
|
|
|
|
|
|
|
|
2023-04-14 16:08:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-04-14 16:08:03 +02:00
|
|
|
|
2023-08-11 17:57:25 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-04-14 16:08:03 +02:00
|
|
|
|
2023-04-14 16:08:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-10-21 15:58:56 -07:00
|
|
|
|
|
|
|
|
|
2022-12-20 11:52:14 -08:00
|
|
|
|
2022-10-21 15:58:56 -07:00
|
|
|
|
2022-12-20 11:52:14 -08:00
|
|
|
|
2022-10-21 15:58:56 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-12-20 11:52:14 -08:00
|
|
|
|
2023-06-20 18:24:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-01-23 19:05:56 +01:00
|
|
|
|
|
|
|
|
|
2023-06-20 18:24:18 +02:00
|
|
|
|
2025-01-23 19:05:56 +01:00
|
|
|
|
2022-10-21 15:58:56 -07:00
|
|
|
|
2023-08-16 08:15:45 +00:00
|
|
|
|
2022-10-21 15:58:56 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-10-23 13:44:39 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-03-01 18:43:46 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-09-02 23:11:36 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-01-21 16:56:15 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-05-16 10:46:21 +02:00
|
|
|
|
2020-01-21 16:56:23 -08:00
|
|
|
|
2020-11-16 10:48:06 +01:00
|
|
|
|
2020-01-21 16:56:23 -08:00
|
|
|
|
2020-01-21 16:56:15 -08:00
|
|
|
|
2021-04-23 11:17:07 -07:00
|
|
|
|
2026-04-03 13:29:28 +02:00
|
|
|
|
|
|
|
|
|
2021-04-23 11:17:07 -07:00
|
|
|
|
2021-10-26 16:29:15 -07:00
|
|
|
|
2020-02-28 15:47:39 -08:00
|
|
|
|
2025-09-02 23:11:36 +02:00
|
|
|
|
|
|
|
|
|
2023-08-16 08:15:45 +00:00
|
|
|
|
|
|
|
|
|
2022-09-26 16:27:38 -07:00
|
|
|
|
|
|
|
|
|
2023-04-14 16:08:02 +02:00
|
|
|
|
2022-09-26 16:27:38 -07:00
|
|
|
|
2022-10-21 15:58:56 -07:00
|
|
|
|
2022-09-26 16:27:38 -07:00
|
|
|
|
2022-10-21 15:58:56 -07:00
|
|
|
|
2022-09-30 08:59:31 -07:00
|
|
|
|
2022-09-26 16:27:38 -07:00
|
|
|
|
|
|
|
|
|
2020-02-28 15:47:39 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-09-30 08:59:31 -07:00
|
|
|
|
2020-02-28 15:47:39 -08:00
|
|
|
|
|
|
|
|
|
2022-09-30 08:59:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-05-16 10:46:21 +02:00
|
|
|
|
2020-03-27 14:48:43 -07:00
|
|
|
|
2020-11-16 10:48:10 +01:00
|
|
|
|
2020-11-27 11:10:25 +01:00
|
|
|
|
2020-11-16 10:48:10 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-03-01 18:43:46 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-07-28 15:12:00 -07:00
|
|
|
|
2020-11-16 10:48:10 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-03-01 18:43:46 +01:00
|
|
|
|
2020-11-27 11:10:25 +01:00
|
|
|
|
2021-06-21 15:54:33 -07:00
|
|
|
|
2021-10-26 16:29:15 -07:00
|
|
|
|
2020-11-16 10:48:10 +01:00
|
|
|
|
|
|
|
|
|
2023-10-23 13:44:39 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-09-30 08:59:31 -07:00
|
|
|
|
2020-11-16 10:48:10 +01:00
|
|
|
|
|
|
|
|
|
2023-08-31 13:52:09 +00:00
|
|
|
|
2020-11-16 10:48:10 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-10-28 09:16:52 +01:00
|
|
|
|
2020-11-16 10:48:10 +01:00
|
|
|
|
mptcp: pr_debug: add missing \n at the end
pr_debug() have been added in various places in MPTCP code to help
developers to debug some situations. With the dynamic debug feature, it
is easy to enable all or some of them, and asks users to reproduce
issues with extra debug.
Many of these pr_debug() don't end with a new line, while no 'pr_cont()'
are used in MPTCP code. So the goal was not to display multiple debug
messages on one line: they were then not missing the '\n' on purpose.
Not having the new line at the end causes these messages to be printed
with a delay, when something else needs to be printed. This issue is not
visible when many messages need to be printed, but it is annoying and
confusing when only specific messages are expected, e.g.
# echo "func mptcp_pm_add_addr_echoed +fmp" \
> /sys/kernel/debug/dynamic_debug/control
# ./mptcp_join.sh "signal address"; \
echo "$(awk '{print $1}' /proc/uptime) - end"; \
sleep 5s; \
echo "$(awk '{print $1}' /proc/uptime) - restart"; \
./mptcp_join.sh "signal address"
013 signal address
(...)
10.75 - end
15.76 - restart
013 signal address
[ 10.367935] mptcp:mptcp_pm_add_addr_echoed: MPTCP: msk=(...)
(...)
=> a delay of 5 seconds: printed with a 10.36 ts, but after 'restart'
which was printed at the 15.76 ts.
The 'Fixes' tag here below points to the first pr_debug() used without
'\n' in net/mptcp. This patch could be split in many small ones, with
different Fixes tag, but it doesn't seem worth it, because it is easy to
re-generate this patch with this simple 'sed' command:
git grep -l pr_debug -- net/mptcp |
xargs sed -i "s/\(pr_debug(\".*[^n]\)\(\"[,)]\)/\1\\\n\2/g"
So in case of conflicts, simply drop the modifications, and launch this
command.
Fixes: f870fa0b5768 ("mptcp: Add MPTCP socket stubs")
Cc: stable@vger.kernel.org
Reviewed-by: Geliang Tang <geliang@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20240826-net-mptcp-close-extra-sf-fin-v1-4-905199fe1172@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26 19:11:21 +02:00
|
|
|
|
2020-11-16 10:48:10 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-03-01 18:43:44 +01:00
|
|
|
|
2021-03-04 13:32:14 -08:00
|
|
|
|
2020-03-27 14:48:39 -07:00
|
|
|
|
|
|
|
|
|
2022-09-30 08:59:31 -07:00
|
|
|
|
2020-01-21 16:56:18 -08:00
|
|
|
|
|
|
|
|
|
2026-04-03 13:29:28 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-03-04 13:32:14 -08:00
|
|
|
|
2026-04-03 13:29:28 +02:00
|
|
|
|
2020-09-14 10:01:10 +02:00
|
|
|
|
2020-02-28 15:47:39 -08:00
|
|
|
|
2020-01-21 16:56:18 -08:00
|
|
|
|
2022-09-30 08:59:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-01-21 16:56:15 -08:00
|
|
|
|
|
|
|
|
|
2024-12-30 19:12:30 +01:00
|
|
|
|
|
|
|
|
|
2026-01-30 20:24:24 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-10-28 09:16:53 +01:00
|
|
|
|
|
|
|
|
|
2021-06-03 16:24:32 -07:00
|
|
|
|
2026-03-30 20:03:35 +08:00
|
|
|
|
2020-02-26 10:14:48 +01:00
|
|
|
|
2025-02-18 19:36:14 +01:00
|
|
|
|
2021-04-23 11:17:08 -07:00
|
|
|
|
2025-10-28 09:16:53 +01:00
|
|
|
|
2020-02-26 10:14:48 +01:00
|
|
|
|
|
|
|
|
|
2025-02-18 19:36:14 +01:00
|
|
|
|
2025-10-28 09:16:53 +01:00
|
|
|
|
2020-02-26 10:14:48 +01:00
|
|
|
|
2025-10-28 09:16:53 +01:00
|
|
|
|
2020-02-26 10:14:48 +01:00
|
|
|
|
|
|
|
|
|
2025-10-28 09:16:53 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-03-30 20:03:35 +08:00
|
|
|
|
2025-10-28 09:16:53 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-04-23 11:17:06 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-02-26 10:14:48 +01:00
|
|
|
|
|
|
|
|
|
2021-06-03 16:24:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-02-26 10:14:48 +01:00
|
|
|
|
|
|
|
|
|
2025-10-28 09:16:53 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-04-23 11:17:08 -07:00
|
|
|
|
2021-12-03 14:35:32 -08:00
|
|
|
|
2025-10-28 09:16:53 +01:00
|
|
|
|
2021-12-03 14:35:32 -08:00
|
|
|
|
2020-02-26 10:14:48 +01:00
|
|
|
|
2026-01-30 20:24:24 +01:00
|
|
|
|
2026-03-30 20:03:35 +08:00
|
|
|
|
|
|
|
|
|
2021-04-23 11:17:08 -07:00
|
|
|
|
2020-02-26 10:14:48 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-12-30 19:12:30 +01:00
|
|
|
|
2020-02-26 10:14:48 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-02-03 19:41:19 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-06-30 21:24:45 +02:00
|
|
|
|
|
|
|
|
|
mptcp: better mptcp-level RTT estimator
The current MPTCP-level RTT estimator has several issues. On high speed
links, the MPTCP-level receive buffer auto-tuning happens with a
frequency well above the TCP-level's one. That in turn can cause
excessive/unneeded receive buffer increase.
On such links, the initial rtt_us value is considerably higher than the
actual delay, and the current mptcp_rcv_space_adjust() updates
msk->rcvq_space.rtt_us with a period equal to the such field previous
value. If the initial rtt_us is 40ms, its first update will happen after
40ms, even if the subflows see actual RTT orders of magnitude lower.
Additionally:
- setting the msk RTT to the maximum among all the subflows RTTs makes
DRS constantly overshooting the rcvbuf size when a subflow has
considerable higher latency than the other(s).
- during unidirectional bulk transfers with multiple active subflows,
the TCP-level RTT estimator occasionally sees considerably higher
value than the real link delay, i.e. when the packet scheduler reacts
to an incoming ACK on given subflow pushing data on a different
subflow.
- currently inactive but still open subflows (i.e. switched to backup
mode) are always considered when computing the msk-level RTT.
Address the all the issues above with a more accurate RTT estimation
strategy: the MPTCP-level RTT is set to the minimum of all the subflows
actually feeding data into the MPTCP receive buffer, using a small
sliding window.
While at it, also use EWMA to compute the msk-level scaling_ratio, to
that MPTCP can avoid traversing the subflow list is
mptcp_rcv_space_adjust().
Use some care to avoid updating msk and ssk level fields too often.
Fixes: a6b118febbab ("mptcp: add receive buffer auto-tuning")
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/20260407-net-next-mptcp-reduce-rbuf-v2-1-0d1d135bf6f6@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-07 10:45:17 +02:00
|
|
|
|
|
|
|
|
|
2020-06-30 21:24:45 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
mptcp: better mptcp-level RTT estimator
The current MPTCP-level RTT estimator has several issues. On high speed
links, the MPTCP-level receive buffer auto-tuning happens with a
frequency well above the TCP-level's one. That in turn can cause
excessive/unneeded receive buffer increase.
On such links, the initial rtt_us value is considerably higher than the
actual delay, and the current mptcp_rcv_space_adjust() updates
msk->rcvq_space.rtt_us with a period equal to the such field previous
value. If the initial rtt_us is 40ms, its first update will happen after
40ms, even if the subflows see actual RTT orders of magnitude lower.
Additionally:
- setting the msk RTT to the maximum among all the subflows RTTs makes
DRS constantly overshooting the rcvbuf size when a subflow has
considerable higher latency than the other(s).
- during unidirectional bulk transfers with multiple active subflows,
the TCP-level RTT estimator occasionally sees considerably higher
value than the real link delay, i.e. when the packet scheduler reacts
to an incoming ACK on given subflow pushing data on a different
subflow.
- currently inactive but still open subflows (i.e. switched to backup
mode) are always considered when computing the msk-level RTT.
Address the all the issues above with a more accurate RTT estimation
strategy: the MPTCP-level RTT is set to the minimum of all the subflows
actually feeding data into the MPTCP receive buffer, using a small
sliding window.
While at it, also use EWMA to compute the msk-level scaling_ratio, to
that MPTCP can avoid traversing the subflow list is
mptcp_rcv_space_adjust().
Use some care to avoid updating msk and ssk level fields too often.
Fixes: a6b118febbab ("mptcp: add receive buffer auto-tuning")
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/20260407-net-next-mptcp-reduce-rbuf-v2-1-0d1d135bf6f6@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-07 10:45:17 +02:00
|
|
|
|
|
|
|
|
|
2020-06-30 21:24:45 +02:00
|
|
|
|
2023-01-06 10:57:17 -08:00
|
|
|
|
2020-06-30 21:24:45 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-02-08 19:03:50 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-06-30 21:24:45 +02:00
|
|
|
|
|
|
|
|
|
2026-02-03 19:41:18 +01:00
|
|
|
|
|
|
|
|
|
2020-06-30 21:24:45 +02:00
|
|
|
|
mptcp: better mptcp-level RTT estimator
The current MPTCP-level RTT estimator has several issues. On high speed
links, the MPTCP-level receive buffer auto-tuning happens with a
frequency well above the TCP-level's one. That in turn can cause
excessive/unneeded receive buffer increase.
On such links, the initial rtt_us value is considerably higher than the
actual delay, and the current mptcp_rcv_space_adjust() updates
msk->rcvq_space.rtt_us with a period equal to the such field previous
value. If the initial rtt_us is 40ms, its first update will happen after
40ms, even if the subflows see actual RTT orders of magnitude lower.
Additionally:
- setting the msk RTT to the maximum among all the subflows RTTs makes
DRS constantly overshooting the rcvbuf size when a subflow has
considerable higher latency than the other(s).
- during unidirectional bulk transfers with multiple active subflows,
the TCP-level RTT estimator occasionally sees considerably higher
value than the real link delay, i.e. when the packet scheduler reacts
to an incoming ACK on given subflow pushing data on a different
subflow.
- currently inactive but still open subflows (i.e. switched to backup
mode) are always considered when computing the msk-level RTT.
Address the all the issues above with a more accurate RTT estimation
strategy: the MPTCP-level RTT is set to the minimum of all the subflows
actually feeding data into the MPTCP receive buffer, using a small
sliding window.
While at it, also use EWMA to compute the msk-level scaling_ratio, to
that MPTCP can avoid traversing the subflow list is
mptcp_rcv_space_adjust().
Use some care to avoid updating msk and ssk level fields too often.
Fixes: a6b118febbab ("mptcp: add receive buffer auto-tuning")
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/20260407-net-next-mptcp-reduce-rbuf-v2-1-0d1d135bf6f6@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-07 10:45:17 +02:00
|
|
|
|
|
|
|
|
|
2020-06-30 21:24:45 +02:00
|
|
|
|
|
|
|
|
|
mptcp: add receive queue awareness in tcp_rcv_space_adjust()
This is the MPTCP counter-part of commit ea33537d8292 ("tcp: add receive
queue awareness in tcp_rcv_space_adjust()").
Prior to this commit:
ESTAB 33165568 0 192.168.255.2:5201 192.168.255.1:53380 \
skmem:(r33076416,rb33554432,t0,tb91136,f448,w0,o0,bl0,d0)
After:
ESTAB 3279168 0 192.168.255.2:5201 192.168.255.1]:53042 \
skmem:(r3190912,rb3719956,t0,tb91136,f1536,w0,o0,bl0,d0)
Same throughput.
Reviewed-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20260407-net-next-mptcp-reduce-rbuf-v2-2-0d1d135bf6f6@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-07 10:45:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-06-30 21:24:45 +02:00
|
|
|
|
|
|
|
|
|
2026-02-03 19:41:20 +01:00
|
|
|
|
mptcp: add receive queue awareness in tcp_rcv_space_adjust()
This is the MPTCP counter-part of commit ea33537d8292 ("tcp: add receive
queue awareness in tcp_rcv_space_adjust()").
Prior to this commit:
ESTAB 33165568 0 192.168.255.2:5201 192.168.255.1:53380 \
skmem:(r33076416,rb33554432,t0,tb91136,f448,w0,o0,bl0,d0)
After:
ESTAB 3279168 0 192.168.255.2:5201 192.168.255.1]:53042 \
skmem:(r3190912,rb3719956,t0,tb91136,f1536,w0,o0,bl0,d0)
Same throughput.
Reviewed-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20260407-net-next-mptcp-reduce-rbuf-v2-2-0d1d135bf6f6@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-07 10:45:18 +02:00
|
|
|
|
2025-09-27 11:40:39 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-06-30 21:24:45 +02:00
|
|
|
|
2025-09-27 11:40:39 +02:00
|
|
|
|
|
|
|
|
|
2025-10-28 12:57:59 +01:00
|
|
|
|
2025-10-28 12:58:01 +01:00
|
|
|
|
mptcp: add receive queue awareness in tcp_rcv_space_adjust()
This is the MPTCP counter-part of commit ea33537d8292 ("tcp: add receive
queue awareness in tcp_rcv_space_adjust()").
Prior to this commit:
ESTAB 33165568 0 192.168.255.2:5201 192.168.255.1:53380 \
skmem:(r33076416,rb33554432,t0,tb91136,f448,w0,o0,bl0,d0)
After:
ESTAB 3279168 0 192.168.255.2:5201 192.168.255.1]:53042 \
skmem:(r3190912,rb3719956,t0,tb91136,f1536,w0,o0,bl0,d0)
Same throughput.
Reviewed-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20260407-net-next-mptcp-reduce-rbuf-v2-2-0d1d135bf6f6@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-07 10:45:18 +02:00
|
|
|
|
2025-09-27 11:40:39 +02:00
|
|
|
|
2020-06-30 21:24:45 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-11-21 18:02:13 +01:00
|
|
|
|
2025-02-18 19:36:18 +01:00
|
|
|
|
2025-11-21 18:02:13 +01:00
|
|
|
|
2020-11-27 11:10:24 +01:00
|
|
|
|
2025-11-21 18:02:13 +01:00
|
|
|
|
2025-02-18 19:36:18 +01:00
|
|
|
|
2025-11-21 18:02:13 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-02-18 19:36:18 +01:00
|
|
|
|
2021-06-10 15:59:44 -07:00
|
|
|
|
2025-11-21 18:02:13 +01:00
|
|
|
|
2025-02-18 19:36:18 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-11-21 18:02:13 +01:00
|
|
|
|
2020-11-27 11:10:24 +01:00
|
|
|
|
2025-11-21 18:02:13 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-08-07 15:49:04 +02:00
|
|
|
|
2025-11-21 18:02:13 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-08-07 15:49:05 +02:00
|
|
|
|
2025-11-21 18:02:13 +01:00
|
|
|
|
|
|
|
|
|
2026-08-07 15:49:05 +02:00
|
|
|
|
2025-11-21 18:02:13 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-08-07 15:49:05 +02:00
|
|
|
|
2025-11-21 18:02:13 +01:00
|
|
|
|
2026-06-02 22:14:08 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-11-21 18:02:13 +01:00
|
|
|
|
2020-02-26 10:14:48 +01:00
|
|
|
|
|
|
|
|
|
2021-12-03 14:35:32 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-02-18 19:36:14 +01:00
|
|
|
|
2021-12-03 14:35:32 -08:00
|
|
|
|
2024-02-02 12:40:09 +01:00
|
|
|
|
2021-12-03 14:35:32 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-01-21 16:56:15 -08:00
|
|
|
|
2026-02-27 15:11:20 +00:00
|
|
|
|
2020-01-21 16:56:15 -08:00
|
|
|
|
|
|
|
|
|
2021-06-03 16:24:32 -07:00
|
|
|
|
|
|
|
|
|
2020-01-21 16:56:26 -08:00
|
|
|
|
|
|
|
|
|
2020-01-21 16:56:15 -08:00
|
|
|
|
2021-04-23 11:17:05 -07:00
|
|
|
|
|
|
|
|
|
2026-02-27 15:11:20 +00:00
|
|
|
|
2021-04-23 11:17:05 -07:00
|
|
|
|
2021-10-26 16:29:15 -07:00
|
|
|
|
2020-11-24 22:51:24 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-09-02 23:11:36 +02:00
|
|
|
|
|
|
|
|
|
net: remove noblock parameter from recvmsg() entities
The internal recvmsg() functions have two parameters 'flags' and 'noblock'
that were merged inside skb_recv_datagram(). As a follow up patch to commit
f4b41f062c42 ("net: remove noblock parameter from skb_recv_datagram()")
this patch removes the separate 'noblock' parameter for recvmsg().
Analogue to the referenced patch for skb_recv_datagram() the 'flags' and
'noblock' parameters are unnecessarily split up with e.g.
err = sk->sk_prot->recvmsg(sk, msg, size, flags & MSG_DONTWAIT,
flags & ~MSG_DONTWAIT, &addr_len);
or in
err = INDIRECT_CALL_2(sk->sk_prot->recvmsg, tcp_recvmsg, udp_recvmsg,
sk, msg, size, flags & MSG_DONTWAIT,
flags & ~MSG_DONTWAIT, &addr_len);
instead of simply using only flags all the time and check for MSG_DONTWAIT
where needed (to preserve for the formerly separated no(n)block condition).
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Link: https://lore.kernel.org/r/20220411124955.154876-1-socketcan@hartkopp.net
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2022-04-11 14:49:55 +02:00
|
|
|
|
2020-01-21 16:56:26 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-12-03 14:35:32 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-12-02 09:16:57 -08:00
|
|
|
|
2026-03-30 20:03:35 +08:00
|
|
|
|
2024-11-08 11:58:16 +01:00
|
|
|
|
2020-01-21 16:56:26 -08:00
|
|
|
|
2025-10-28 09:16:53 +01:00
|
|
|
|
2026-03-30 20:03:35 +08:00
|
|
|
|
|
|
|
|
|
2020-02-26 10:14:48 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-01-21 16:56:26 -08:00
|
|
|
|
2020-02-26 10:14:48 +01:00
|
|
|
|
2020-01-21 16:56:26 -08:00
|
|
|
|
2025-11-21 18:02:13 +01:00
|
|
|
|
2021-02-11 15:30:41 -08:00
|
|
|
|
2020-11-19 11:46:03 -08:00
|
|
|
|
2024-06-05 09:15:42 +02:00
|
|
|
|
2020-01-21 16:56:26 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-04-03 13:29:29 +02:00
|
|
|
|
|
|
|
|
|
2020-01-21 16:56:26 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-09-27 11:40:41 +02:00
|
|
|
|
2020-01-21 16:56:26 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
mptcp: pr_debug: add missing \n at the end
pr_debug() have been added in various places in MPTCP code to help
developers to debug some situations. With the dynamic debug feature, it
is easy to enable all or some of them, and asks users to reproduce
issues with extra debug.
Many of these pr_debug() don't end with a new line, while no 'pr_cont()'
are used in MPTCP code. So the goal was not to display multiple debug
messages on one line: they were then not missing the '\n' on purpose.
Not having the new line at the end causes these messages to be printed
with a delay, when something else needs to be printed. This issue is not
visible when many messages need to be printed, but it is annoying and
confusing when only specific messages are expected, e.g.
# echo "func mptcp_pm_add_addr_echoed +fmp" \
> /sys/kernel/debug/dynamic_debug/control
# ./mptcp_join.sh "signal address"; \
echo "$(awk '{print $1}' /proc/uptime) - end"; \
sleep 5s; \
echo "$(awk '{print $1}' /proc/uptime) - restart"; \
./mptcp_join.sh "signal address"
013 signal address
(...)
10.75 - end
15.76 - restart
013 signal address
[ 10.367935] mptcp:mptcp_pm_add_addr_echoed: MPTCP: msk=(...)
(...)
=> a delay of 5 seconds: printed with a 10.36 ts, but after 'restart'
which was printed at the 15.76 ts.
The 'Fixes' tag here below points to the first pr_debug() used without
'\n' in net/mptcp. This patch could be split in many small ones, with
different Fixes tag, but it doesn't seem worth it, because it is easy to
re-generate this patch with this simple 'sed' command:
git grep -l pr_debug -- net/mptcp |
xargs sed -i "s/\(pr_debug(\".*[^n]\)\(\"[,)]\)/\1\\\n\2/g"
So in case of conflicts, simply drop the modifications, and launch this
command.
Fixes: f870fa0b5768 ("mptcp: Add MPTCP socket stubs")
Cc: stable@vger.kernel.org
Reviewed-by: Geliang Tang <geliang@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20240826-net-mptcp-close-extra-sf-fin-v1-4-905199fe1172@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26 19:11:21 +02:00
|
|
|
|
2024-12-30 19:12:31 +01:00
|
|
|
|
2026-03-30 20:03:35 +08:00
|
|
|
|
2024-11-08 11:58:16 +01:00
|
|
|
|
2026-09-13 10:30:05 +00:00
|
|
|
|
2024-11-08 11:58:16 +01:00
|
|
|
|
|
|
|
|
|
2020-01-21 16:56:26 -08:00
|
|
|
|
2021-06-21 15:54:35 -07:00
|
|
|
|
2024-12-30 19:12:31 +01:00
|
|
|
|
|
|
|
|
|
2020-02-26 10:14:48 +01:00
|
|
|
|
2021-06-03 16:24:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-12-03 14:35:32 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-06-03 16:24:32 -07:00
|
|
|
|
|
|
|
|
|
2025-02-18 19:36:14 +01:00
|
|
|
|
|
|
|
|
|
2020-06-30 21:24:45 +02:00
|
|
|
|
2020-01-21 16:56:18 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-03-27 14:48:44 -07:00
|
|
|
|
|
|
|
|
|
2025-11-24 17:50:13 +00:00
|
|
|
|
2021-03-26 11:26:30 -07:00
|
|
|
|
2020-03-27 14:48:44 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-03-26 11:26:30 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-03-27 14:48:44 -07:00
|
|
|
|
|
|
|
|
|
2022-01-06 16:20:26 -08:00
|
|
|
|
2020-03-27 14:48:44 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-09-16 12:52:48 +02:00
|
|
|
|
2020-11-16 10:48:09 +01:00
|
|
|
|
2025-11-24 17:50:12 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-16 10:48:09 +01:00
|
|
|
|
|
|
|
|
|
2020-11-24 17:24:46 +01:00
|
|
|
|
2020-11-16 10:48:09 +01:00
|
|
|
|
|
|
|
|
|
2020-03-27 14:48:48 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-08-21 15:25:18 -07:00
|
|
|
|
2020-03-27 14:48:48 -07:00
|
|
|
|
2021-08-13 15:15:42 -07:00
|
|
|
|
2020-03-27 14:48:48 -07:00
|
|
|
|
2021-08-13 15:15:42 -07:00
|
|
|
|
2020-03-27 14:48:48 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-08-13 15:15:45 -07:00
|
|
|
|
2020-09-14 10:01:17 +02:00
|
|
|
|
|
|
|
|
|
2021-08-13 15:15:42 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-19 11:45:56 -08:00
|
|
|
|
2020-03-27 14:48:48 -07:00
|
|
|
|
2024-08-26 19:11:20 +02:00
|
|
|
|
2020-03-27 14:48:48 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-08-13 15:15:42 -07:00
|
|
|
|
|
|
|
|
|
2020-03-27 14:48:48 -07:00
|
|
|
|
|
|
|
|
|
2021-08-13 15:15:42 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-03-27 14:48:48 -07:00
|
|
|
|
|
|
|
|
|
2021-08-13 15:15:43 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-11-10 15:23:18 -08:00
|
|
|
|
2021-08-13 15:15:43 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-09-24 14:12:34 -07:00
|
|
|
|
2021-08-13 15:15:43 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-01-06 16:20:16 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-10-18 11:23:55 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-12-12 13:54:04 +01:00
|
|
|
|
2023-10-18 11:23:55 -07:00
|
|
|
|
|
|
|
|
|
2025-12-12 13:54:04 +01:00
|
|
|
|
2023-10-18 11:23:55 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
mptcp: fix stale skb->sk reference on subflow close
The backlog list is updated by mptcp_data_ready() under
mptcp_data_lock(). The cleanup of backlog references to a closing
subflow, however, was performed in mptcp_close_ssk(), before
__mptcp_close_ssk() acquires the ssk lock, and while holding neither
the ssk lock nor mptcp_data_lock().
Because that traversal ran without mptcp_data_lock(), concurrent softirq
RX processing on another CPU (subflow_data_ready() -> mptcp_data_ready()
-> __mptcp_add_backlog(), under mptcp_data_lock()) could add a backlog
entry referencing the ssk while the cleanup loop was in progress. Such
an entry could be missed by the cleanup, or the concurrent list update
could corrupt the traversal, leaving skb->sk pointing at the ssk after
it is freed.
A later mptcp_backlog_purge() then dereferences the stale pointer,
triggering a warning in inet_sock_destruct() (ssk->sk_rmem_alloc != 0)
followed by a use-after-free in mptcp_backlog_purge().
Fix this by moving the backlog cleanup into __mptcp_close_ssk(), after
subflow->closing is set to 1 and while the ssk lock is still held,
serialized under mptcp_data_lock(). The cleanup runs only on the push
path (MPTCP_CF_PUSH), where backlog references accumulate; on other
teardown paths the caller already handles cleanup.
With subflow->closing set and mptcp_data_lock() held across the purge,
any concurrent mptcp_data_ready() either completes its enqueue before
the purge runs and is caught, or observes closing=1 and bails out. Once
mptcp_data_unlock() is reached, no new skb referencing the ssk can be
enqueued, so the cleanup is exhaustive.
Remove the unprotected traversal from mptcp_close_ssk() entirely.
Fixes: ee458a3f314e ("mptcp: introduce mptcp-level backlog")
Cc: stable@vger.kernel.org
Suggested-by: Paolo Abeni <pabeni@redhat.com>
Reported-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/621
Signed-off-by: Kalpan Jani <kalpan.jani@mpiricsoftware.com>
Acked-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20260722-net-mptcp-misc-fixes-7-2-rc5-v1-3-6fb595bc86ef@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-22 00:14:40 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-01-21 16:56:18 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-02-12 15:59:55 -08:00
|
|
|
|
2022-01-06 16:20:16 -08:00
|
|
|
|
|
|
|
|
|
2020-01-21 16:56:18 -08:00
|
|
|
|
2021-03-04 13:32:08 -08:00
|
|
|
|
2023-04-17 16:00:41 +02:00
|
|
|
|
2025-11-21 18:02:11 +01:00
|
|
|
|
2023-04-17 16:00:41 +02:00
|
|
|
|
2025-11-21 18:02:10 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
mptcp: fix stale skb->sk reference on subflow close
The backlog list is updated by mptcp_data_ready() under
mptcp_data_lock(). The cleanup of backlog references to a closing
subflow, however, was performed in mptcp_close_ssk(), before
__mptcp_close_ssk() acquires the ssk lock, and while holding neither
the ssk lock nor mptcp_data_lock().
Because that traversal ran without mptcp_data_lock(), concurrent softirq
RX processing on another CPU (subflow_data_ready() -> mptcp_data_ready()
-> __mptcp_add_backlog(), under mptcp_data_lock()) could add a backlog
entry referencing the ssk while the cleanup loop was in progress. Such
an entry could be missed by the cleanup, or the concurrent list update
could corrupt the traversal, leaving skb->sk pointing at the ssk after
it is freed.
A later mptcp_backlog_purge() then dereferences the stale pointer,
triggering a warning in inet_sock_destruct() (ssk->sk_rmem_alloc != 0)
followed by a use-after-free in mptcp_backlog_purge().
Fix this by moving the backlog cleanup into __mptcp_close_ssk(), after
subflow->closing is set to 1 and while the ssk lock is still held,
serialized under mptcp_data_lock(). The cleanup runs only on the push
path (MPTCP_CF_PUSH), where backlog references accumulate; on other
teardown paths the caller already handles cleanup.
With subflow->closing set and mptcp_data_lock() held across the purge,
any concurrent mptcp_data_ready() either completes its enqueue before
the purge runs and is caught, or observes closing=1 and bails out. Once
mptcp_data_unlock() is reached, no new skb referencing the ssk can be
enqueued, so the cleanup is exhaustive.
Remove the unprotected traversal from mptcp_close_ssk() entirely.
Fixes: ee458a3f314e ("mptcp: introduce mptcp-level backlog")
Cc: stable@vger.kernel.org
Suggested-by: Paolo Abeni <pabeni@redhat.com>
Reported-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/621
Signed-off-by: Kalpan Jani <kalpan.jani@mpiricsoftware.com>
Acked-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20260722-net-mptcp-misc-fixes-7-2-rc5-v1-3-6fb595bc86ef@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-07-22 00:14:40 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-11-21 18:02:11 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-04-17 16:00:41 +02:00
|
|
|
|
2023-09-16 12:52:49 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-04-17 16:00:41 +02:00
|
|
|
|
2023-09-16 12:52:49 +02:00
|
|
|
|
|
|
|
|
|
2023-04-17 16:00:41 +02:00
|
|
|
|
|
|
|
|
|
2023-10-23 13:44:34 -07:00
|
|
|
|
2023-04-17 16:00:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-03-04 13:32:08 -08:00
|
|
|
|
2023-08-11 17:57:26 +02:00
|
|
|
|
2022-01-06 16:20:16 -08:00
|
|
|
|
|
|
|
|
|
2020-01-21 16:56:18 -08:00
|
|
|
|
2025-11-18 08:20:24 +01:00
|
|
|
|
|
|
|
|
|
2022-01-06 16:20:16 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-12-12 13:54:04 +01:00
|
|
|
|
2022-01-06 16:20:16 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-12-09 12:03:31 +01:00
|
|
|
|
|
|
|
|
|
2020-11-16 10:48:09 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-03-09 15:49:59 +01:00
|
|
|
|
2020-11-16 10:48:09 +01:00
|
|
|
|
|
|
|
|
|
2020-12-09 12:03:31 +01:00
|
|
|
|
2020-11-16 10:48:09 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-04-17 16:00:41 +02:00
|
|
|
|
|
|
|
|
|
2023-09-16 12:52:47 +02:00
|
|
|
|
2020-11-16 10:48:09 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-03-04 13:32:08 -08:00
|
|
|
|
2021-03-04 13:32:12 -08:00
|
|
|
|
2023-05-31 12:37:06 -07:00
|
|
|
|
2021-03-04 13:32:12 -08:00
|
|
|
|
2022-01-06 16:20:16 -08:00
|
|
|
|
2023-10-23 13:44:42 -07:00
|
|
|
|
2021-08-13 15:15:43 -07:00
|
|
|
|
|
|
|
|
|
2023-09-16 12:52:49 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-12-22 13:47:23 +01:00
|
|
|
|
2023-09-16 12:52:49 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-01-21 16:56:15 -08:00
|
|
|
|
|
|
|
|
|
2021-02-12 15:59:55 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-01-27 20:27:23 +01:00
|
|
|
|
|
|
|
|
|
2024-08-28 08:14:35 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-02-12 16:00:01 -08:00
|
|
|
|
|
|
|
|
|
2022-01-06 16:20:23 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-10-25 16:37:05 -07:00
|
|
|
|
2022-01-06 16:20:23 -08:00
|
|
|
|
2022-01-06 16:20:16 -08:00
|
|
|
|
2021-02-12 15:59:55 -08:00
|
|
|
|
|
|
|
|
|
2020-02-26 12:19:03 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-03-09 15:49:59 +01:00
|
|
|
|
2020-10-09 19:00:01 +02:00
|
|
|
|
|
|
|
|
|
2023-03-09 15:49:59 +01:00
|
|
|
|
2020-10-09 19:00:01 +02:00
|
|
|
|
2021-02-04 15:23:30 -08:00
|
|
|
|
|
|
|
|
|
2022-09-06 22:55:39 +02:00
|
|
|
|
2020-10-09 19:00:01 +02:00
|
|
|
|
mptcp: close subflow when receiving TCP+FIN
When a peer decides to close one subflow in the middle of a connection
having multiple subflows, the receiver of the first FIN should accept
that, and close the subflow on its side as well. If not, the subflow
will stay half closed, and would even continue to be used until the end
of the MPTCP connection or a reset from the network.
The issue has not been seen before, probably because the in-kernel
path-manager always sends a RM_ADDR before closing the subflow. Upon the
reception of this RM_ADDR, the other peer will initiate the closure on
its side as well. On the other hand, if the RM_ADDR is lost, or if the
path-manager of the other peer only closes the subflow without sending a
RM_ADDR, the subflow would switch to TCP_CLOSE_WAIT, but that's it,
leaving the subflow half-closed.
So now, when the subflow switches to the TCP_CLOSE_WAIT state, and if
the MPTCP connection has not been closed before with a DATA_FIN, the
kernel owning the subflow schedules its worker to initiate the closure
on its side as well.
This issue can be easily reproduced with packetdrill, as visible in [1],
by creating an additional subflow, injecting a FIN+ACK before sending
the DATA_FIN, and expecting a FIN+ACK in return.
Fixes: 40947e13997a ("mptcp: schedule worker when subflow is closed")
Cc: stable@vger.kernel.org
Link: https://github.com/multipath-tcp/packetdrill/pull/154 [1]
Reviewed-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20240826-net-mptcp-close-extra-sf-fin-v1-1-905199fe1172@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26 19:11:18 +02:00
|
|
|
|
2020-10-09 19:00:01 +02:00
|
|
|
|
mptcp: close subflow when receiving TCP+FIN
When a peer decides to close one subflow in the middle of a connection
having multiple subflows, the receiver of the first FIN should accept
that, and close the subflow on its side as well. If not, the subflow
will stay half closed, and would even continue to be used until the end
of the MPTCP connection or a reset from the network.
The issue has not been seen before, probably because the in-kernel
path-manager always sends a RM_ADDR before closing the subflow. Upon the
reception of this RM_ADDR, the other peer will initiate the closure on
its side as well. On the other hand, if the RM_ADDR is lost, or if the
path-manager of the other peer only closes the subflow without sending a
RM_ADDR, the subflow would switch to TCP_CLOSE_WAIT, but that's it,
leaving the subflow half-closed.
So now, when the subflow switches to the TCP_CLOSE_WAIT state, and if
the MPTCP connection has not been closed before with a DATA_FIN, the
kernel owning the subflow schedules its worker to initiate the closure
on its side as well.
This issue can be easily reproduced with packetdrill, as visible in [1],
by creating an additional subflow, injecting a FIN+ACK before sending
the DATA_FIN, and expecting a FIN+ACK in return.
Fixes: 40947e13997a ("mptcp: schedule worker when subflow is closed")
Cc: stable@vger.kernel.org
Link: https://github.com/multipath-tcp/packetdrill/pull/154 [1]
Reviewed-by: Mat Martineau <martineau@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20240826-net-mptcp-close-extra-sf-fin-v1-1-905199fe1172@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26 19:11:18 +02:00
|
|
|
|
|
|
|
|
|
2025-11-18 08:20:21 +01:00
|
|
|
|
|
|
|
|
|
2020-10-09 19:00:01 +02:00
|
|
|
|
|
|
|
|
|
2021-02-12 15:59:56 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-03-09 15:49:59 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-10-09 19:00:01 +02:00
|
|
|
|
|
|
|
|
|
2023-09-16 12:52:49 +02:00
|
|
|
|
2020-11-16 10:48:09 +01:00
|
|
|
|
2023-09-16 12:52:49 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-16 10:48:09 +01:00
|
|
|
|
2023-09-16 12:52:49 +02:00
|
|
|
|
2023-10-23 13:44:34 -07:00
|
|
|
|
2020-11-16 10:48:09 +01:00
|
|
|
|
|
|
|
|
|
2020-12-10 14:25:04 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-11-10 15:23:20 -08:00
|
|
|
|
2020-12-10 14:25:04 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-09-06 22:55:39 +02:00
|
|
|
|
2020-12-10 14:25:04 -08:00
|
|
|
|
2021-06-21 15:54:34 -07:00
|
|
|
|
2020-12-10 14:25:04 -08:00
|
|
|
|
2021-06-21 15:54:34 -07:00
|
|
|
|
2020-12-10 14:25:04 -08:00
|
|
|
|
2024-04-25 11:13:39 +08:00
|
|
|
|
2020-12-10 14:25:04 -08:00
|
|
|
|
|
|
|
|
|
2021-06-21 15:54:34 -07:00
|
|
|
|
2020-12-10 14:25:04 -08:00
|
|
|
|
|
|
|
|
|
2022-09-30 08:59:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-03-15 20:57:45 +00:00
|
|
|
|
2022-09-30 08:59:31 -07:00
|
|
|
|
|
|
|
|
|
2023-03-15 20:57:45 +00:00
|
|
|
|
2022-09-30 08:59:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-03-15 20:57:45 +00:00
|
|
|
|
2022-09-30 08:59:31 -07:00
|
|
|
|
|
|
|
|
|
2023-12-22 13:47:23 +01:00
|
|
|
|
2023-05-31 12:37:07 -07:00
|
|
|
|
2020-12-10 14:25:04 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-09-30 08:59:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-12-10 14:25:04 -08:00
|
|
|
|
|
|
|
|
|
2026-08-07 15:49:03 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-02-26 10:14:47 +01:00
|
|
|
|
2025-07-14 18:41:44 +02:00
|
|
|
|
2021-03-04 13:32:13 -08:00
|
|
|
|
2023-08-21 15:25:20 -07:00
|
|
|
|
2021-03-04 13:32:13 -08:00
|
|
|
|
2026-08-07 15:49:01 +02:00
|
|
|
|
2021-03-04 13:32:13 -08:00
|
|
|
|
2023-08-21 15:25:20 -07:00
|
|
|
|
|
|
|
|
|
2026-08-07 15:49:03 +02:00
|
|
|
|
2023-08-21 15:25:20 -07:00
|
|
|
|
2021-03-04 13:32:13 -08:00
|
|
|
|
2023-08-21 15:25:20 -07:00
|
|
|
|
2021-03-04 13:32:13 -08:00
|
|
|
|
2023-08-21 15:25:20 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-08-07 15:49:03 +02:00
|
|
|
|
2023-08-21 15:25:20 -07:00
|
|
|
|
|
|
|
|
|
2025-07-14 18:41:44 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-12-05 19:55:17 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-07-14 18:41:44 +02:00
|
|
|
|
|
|
|
|
|
2025-12-05 19:55:17 +01:00
|
|
|
|
|
|
|
|
|
2025-07-14 18:41:44 +02:00
|
|
|
|
|
|
|
|
|
2026-08-07 15:49:01 +02:00
|
|
|
|
2025-07-14 18:41:44 +02:00
|
|
|
|
|
|
|
|
|
2023-08-21 15:25:20 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-07-14 18:41:45 +02:00
|
|
|
|
2023-08-21 15:25:20 -07:00
|
|
|
|
2025-07-14 18:41:44 +02:00
|
|
|
|
2023-08-21 15:25:20 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-06-17 16:46:17 -07:00
|
|
|
|
2026-08-07 15:49:01 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-08-07 15:49:03 +02:00
|
|
|
|
|
|
|
|
|
2026-08-07 15:49:01 +02:00
|
|
|
|
|
|
|
|
|
2026-08-07 15:49:02 +02:00
|
|
|
|
|
|
|
|
|
2026-08-07 15:49:03 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-08-07 15:49:01 +02:00
|
|
|
|
2026-08-07 15:49:03 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-08-07 15:49:01 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-03-04 13:32:13 -08:00
|
|
|
|
2021-09-24 14:12:38 -07:00
|
|
|
|
|
|
|
|
|
2023-09-16 12:52:48 +02:00
|
|
|
|
|
|
|
|
|
2025-11-25 17:59:11 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-03-04 13:32:13 -08:00
|
|
|
|
|
|
|
|
|
2022-06-27 18:02:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-09-16 12:52:48 +02:00
|
|
|
|
2022-06-27 18:02:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-09-16 12:52:49 +02:00
|
|
|
|
2022-06-27 18:02:37 -07:00
|
|
|
|
|
|
|
|
|
2024-11-07 13:36:57 +03:00
|
|
|
|
|
|
|
|
|
2022-06-27 18:02:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-09-16 12:52:49 +02:00
|
|
|
|
2022-06-27 18:02:37 -07:00
|
|
|
|
2025-11-24 17:50:12 +00:00
|
|
|
|
2022-06-27 18:02:37 -07:00
|
|
|
|
|
|
|
|
|
2022-04-26 14:57:15 -07:00
|
|
|
|
|
|
|
|
|
2022-06-27 18:02:37 -07:00
|
|
|
|
2022-04-26 14:57:15 -07:00
|
|
|
|
|
|
|
|
|
2022-06-27 18:02:37 -07:00
|
|
|
|
|
|
|
|
|
2022-04-26 14:57:15 -07:00
|
|
|
|
mptcp: pr_debug: add missing \n at the end
pr_debug() have been added in various places in MPTCP code to help
developers to debug some situations. With the dynamic debug feature, it
is easy to enable all or some of them, and asks users to reproduce
issues with extra debug.
Many of these pr_debug() don't end with a new line, while no 'pr_cont()'
are used in MPTCP code. So the goal was not to display multiple debug
messages on one line: they were then not missing the '\n' on purpose.
Not having the new line at the end causes these messages to be printed
with a delay, when something else needs to be printed. This issue is not
visible when many messages need to be printed, but it is annoying and
confusing when only specific messages are expected, e.g.
# echo "func mptcp_pm_add_addr_echoed +fmp" \
> /sys/kernel/debug/dynamic_debug/control
# ./mptcp_join.sh "signal address"; \
echo "$(awk '{print $1}' /proc/uptime) - end"; \
sleep 5s; \
echo "$(awk '{print $1}' /proc/uptime) - restart"; \
./mptcp_join.sh "signal address"
013 signal address
(...)
10.75 - end
15.76 - restart
013 signal address
[ 10.367935] mptcp:mptcp_pm_add_addr_echoed: MPTCP: msk=(...)
(...)
=> a delay of 5 seconds: printed with a 10.36 ts, but after 'restart'
which was printed at the 15.76 ts.
The 'Fixes' tag here below points to the first pr_debug() used without
'\n' in net/mptcp. This patch could be split in many small ones, with
different Fixes tag, but it doesn't seem worth it, because it is easy to
re-generate this patch with this simple 'sed' command:
git grep -l pr_debug -- net/mptcp |
xargs sed -i "s/\(pr_debug(\".*[^n]\)\(\"[,)]\)/\1\\\n\2/g"
So in case of conflicts, simply drop the modifications, and launch this
command.
Fixes: f870fa0b5768 ("mptcp: Add MPTCP socket stubs")
Cc: stable@vger.kernel.org
Reviewed-by: Geliang Tang <geliang@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20240826-net-mptcp-close-extra-sf-fin-v1-4-905199fe1172@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26 19:11:21 +02:00
|
|
|
|
2022-06-27 18:02:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-04-26 14:57:15 -07:00
|
|
|
|
|
|
|
|
|
2025-11-21 18:02:12 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-09-30 08:59:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-12-22 13:47:23 +01:00
|
|
|
|
2025-11-21 18:02:12 +01:00
|
|
|
|
2025-12-12 13:54:04 +01:00
|
|
|
|
2025-11-18 08:20:24 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-11-25 19:53:29 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-08-27 09:59:36 +00:00
|
|
|
|
2025-11-18 08:20:24 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-09-30 08:59:32 -07:00
|
|
|
|
|
|
|
|
|
2021-03-04 13:32:13 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-11-10 15:23:20 -08:00
|
|
|
|
2022-06-27 18:02:37 -07:00
|
|
|
|
2021-03-04 13:32:13 -08:00
|
|
|
|
2020-02-26 10:14:47 +01:00
|
|
|
|
|
|
|
|
|
2020-11-16 10:48:09 +01:00
|
|
|
|
2023-04-11 22:42:10 +02:00
|
|
|
|
2020-11-16 10:48:09 +01:00
|
|
|
|
|
|
|
|
|
2020-12-10 14:25:04 -08:00
|
|
|
|
|
|
|
|
|
2025-03-07 12:21:48 +01:00
|
|
|
|
2020-07-07 14:40:48 +02:00
|
|
|
|
2023-06-20 18:24:21 +02:00
|
|
|
|
|
|
|
|
|
2020-07-28 15:12:06 -07:00
|
|
|
|
|
|
|
|
|
2023-03-09 15:49:59 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-09-16 12:52:49 +02:00
|
|
|
|
2025-11-18 08:20:23 +01:00
|
|
|
|
|
|
|
|
|
2023-09-16 12:52:49 +02:00
|
|
|
|
2025-11-18 08:20:23 +01:00
|
|
|
|
|
|
|
|
|
2023-09-16 12:52:49 +02:00
|
|
|
|
|
|
|
|
|
2023-06-20 18:30:21 +02:00
|
|
|
|
2023-09-16 12:52:49 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-16 10:48:09 +01:00
|
|
|
|
|
|
|
|
|
2021-03-04 13:32:13 -08:00
|
|
|
|
|
|
|
|
|
2020-03-27 14:48:48 -07:00
|
|
|
|
2022-06-27 18:02:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-04-26 14:57:15 -07:00
|
|
|
|
2020-03-27 14:48:48 -07:00
|
|
|
|
2020-02-26 10:14:47 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-08-11 17:57:27 +02:00
|
|
|
|
2020-01-21 16:56:15 -08:00
|
|
|
|
2026-08-12 16:55:39 +02:00
|
|
|
|
2020-01-21 16:56:18 -08:00
|
|
|
|
2026-08-12 16:55:39 +02:00
|
|
|
|
2020-01-21 16:56:18 -08:00
|
|
|
|
|
|
|
|
|
2020-03-27 14:48:40 -07:00
|
|
|
|
2020-03-27 14:48:43 -07:00
|
|
|
|
2025-11-21 18:02:12 +01:00
|
|
|
|
2020-02-26 10:14:47 +01:00
|
|
|
|
2020-09-14 10:01:12 +02:00
|
|
|
|
2020-11-16 10:48:07 +01:00
|
|
|
|
2026-08-12 16:55:39 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-10-23 13:44:38 -07:00
|
|
|
|
2025-11-21 18:02:12 +01:00
|
|
|
|
mptcp: better mptcp-level RTT estimator
The current MPTCP-level RTT estimator has several issues. On high speed
links, the MPTCP-level receive buffer auto-tuning happens with a
frequency well above the TCP-level's one. That in turn can cause
excessive/unneeded receive buffer increase.
On such links, the initial rtt_us value is considerably higher than the
actual delay, and the current mptcp_rcv_space_adjust() updates
msk->rcvq_space.rtt_us with a period equal to the such field previous
value. If the initial rtt_us is 40ms, its first update will happen after
40ms, even if the subflows see actual RTT orders of magnitude lower.
Additionally:
- setting the msk RTT to the maximum among all the subflows RTTs makes
DRS constantly overshooting the rcvbuf size when a subflow has
considerable higher latency than the other(s).
- during unidirectional bulk transfers with multiple active subflows,
the TCP-level RTT estimator occasionally sees considerably higher
value than the real link delay, i.e. when the packet scheduler reacts
to an incoming ACK on given subflow pushing data on a different
subflow.
- currently inactive but still open subflows (i.e. switched to backup
mode) are always considered when computing the msk-level RTT.
Address the all the issues above with a more accurate RTT estimation
strategy: the MPTCP-level RTT is set to the minimum of all the subflows
actually feeding data into the MPTCP receive buffer, using a small
sliding window.
While at it, also use EWMA to compute the msk-level scaling_ratio, to
that MPTCP can avoid traversing the subflow list is
mptcp_rcv_space_adjust().
Use some care to avoid updating msk and ssk level fields too often.
Fixes: a6b118febbab ("mptcp: add receive buffer auto-tuning")
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/20260407-net-next-mptcp-reduce-rbuf-v2-1-0d1d135bf6f6@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-07 10:45:17 +02:00
|
|
|
|
2020-01-21 16:56:18 -08:00
|
|
|
|
2023-05-31 12:37:06 -07:00
|
|
|
|
2020-02-26 12:19:03 +01:00
|
|
|
|
2021-06-17 16:46:07 -07:00
|
|
|
|
2025-07-14 18:41:45 +02:00
|
|
|
|
|
|
|
|
|
2021-08-13 15:15:43 -07:00
|
|
|
|
2023-06-20 18:30:17 +02:00
|
|
|
|
mptcp: add last time fields in mptcp_info
This patch adds "last time" fields last_data_sent, last_data_recv and
last_ack_recv in struct mptcp_sock to record the last time data_sent,
data_recv and ack_recv happened. They all are initialized as
tcp_jiffies32 in __mptcp_init_sock(), and updated as tcp_jiffies32 too
when data is sent in __subflow_push_pending(), data is received in
__mptcp_move_skbs_from_subflow(), and ack is received in ack_update_msk().
Similar to tcpi_last_data_sent, tcpi_last_data_recv and tcpi_last_ack_recv
exposed with TCP, this patch exposes the last time "an action happened" for
MPTCP in mptcp_info, named mptcpi_last_data_sent, mptcpi_last_data_recv and
mptcpi_last_ack_recv, calculated in mptcp_diag_fill_info() as the time
deltas between now and the newly added last time fields in mptcp_sock.
Since msk->last_ack_recv needs to be protected by mptcp_data_lock/unlock,
and lock_sock_fast can sleep and be quite slow, move the entire
mptcp_data_lock/unlock block after the lock/unlock_sock_fast block.
Then mptcpi_last_data_sent and mptcpi_last_data_recv are set in
lock/unlock_sock_fast block, while mptcpi_last_ack_recv is set in
mptcp_data_lock/unlock block, which is protected by a spinlock and
should not block for too long.
Also add three reserved bytes in struct mptcp_info not to have holes in
this structure exposed to userspace.
Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/446
Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn>
Reviewed-by: Mat Martineau <martineau@kernel.org>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://lore.kernel.org/r/20240410-upstream-net-next-20240405-mptcp-last-time-info-v2-1-f95bd6b33e51@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-04-10 11:48:24 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
mptcp: cope with later TCP fallback
With MPTCP v1, passive connections can fallback to TCP after the
subflow becomes established:
syn + MP_CAPABLE ->
<- syn, ack + MP_CAPABLE
ack, seq = 3 ->
// OoO packet is accepted because in-sequence
// passive socket is created, is in ESTABLISHED
// status and tentatively as MP_CAPABLE
ack, seq = 2 ->
// no MP_CAPABLE opt, subflow should fallback to TCP
We can't use the 'subflow' socket fallback, as we don't have
it available for passive connection.
Instead, when the fallback is detected, replace the mptcp
socket with the underlying TCP subflow. Beyond covering
the above scenario, it makes a TCP fallback socket as efficient
as plain TCP ones.
Co-developed-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Christoph Paasch <cpaasch@apple.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2020-01-21 16:56:33 -08:00
|
|
|
|
2020-03-27 14:48:38 -07:00
|
|
|
|
2025-07-14 18:41:44 +02:00
|
|
|
|
2020-03-27 14:48:38 -07:00
|
|
|
|
2020-03-27 14:48:44 -07:00
|
|
|
|
2025-11-24 17:50:13 +00:00
|
|
|
|
2025-11-24 17:50:12 +00:00
|
|
|
|
2020-01-21 16:56:15 -08:00
|
|
|
|
|
|
|
|
|
2022-01-06 16:20:16 -08:00
|
|
|
|
2020-01-21 16:56:28 -08:00
|
|
|
|
2021-05-25 14:23:10 -07:00
|
|
|
|
2022-01-06 16:20:16 -08:00
|
|
|
|
|
|
|
|
|
2024-05-13 18:13:29 -07:00
|
|
|
|
|
|
|
|
|
2022-01-06 16:20:16 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-03-27 14:48:50 -07:00
|
|
|
|
2023-08-21 15:25:16 -07:00
|
|
|
|
2020-03-27 14:48:43 -07:00
|
|
|
|
2023-08-11 17:57:27 +02:00
|
|
|
|
2020-09-24 08:29:54 +08:00
|
|
|
|
2020-03-27 14:48:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-10-21 12:25:26 +02:00
|
|
|
|
2023-08-21 15:25:16 -07:00
|
|
|
|
|
|
|
|
|
2024-10-21 12:25:26 +02:00
|
|
|
|
2023-08-21 15:25:16 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-10-20 19:48:51 +02:00
|
|
|
|
|
|
|
|
|
2021-05-25 14:23:10 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-01-06 16:20:16 -08:00
|
|
|
|
2021-05-25 14:23:10 -07:00
|
|
|
|
2020-03-27 14:48:45 -07:00
|
|
|
|
2023-01-06 10:57:18 -08:00
|
|
|
|
|
|
|
|
|
2026-02-06 14:09:24 +01:00
|
|
|
|
2020-03-27 14:48:45 -07:00
|
|
|
|
2020-03-27 14:48:43 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-10-28 09:16:52 +01:00
|
|
|
|
2020-03-27 14:48:43 -07:00
|
|
|
|
2020-03-27 14:48:45 -07:00
|
|
|
|
2020-01-21 16:56:28 -08:00
|
|
|
|
|
|
|
|
|
mptcp: fix unreleased socket in accept queue
The mptcp socket and its subflow sockets in accept queue can't be
released after the process exit.
While the release of a mptcp socket in listening state, the
corresponding tcp socket will be released too. Meanwhile, the tcp
socket in the unaccept queue will be released too. However, only init
subflow is in the unaccept queue, and the joined subflow is not in the
unaccept queue, which makes the joined subflow won't be released, and
therefore the corresponding unaccepted mptcp socket will not be released
to.
This can be reproduced easily with following steps:
1. create 2 namespace and veth:
$ ip netns add mptcp-client
$ ip netns add mptcp-server
$ sysctl -w net.ipv4.conf.all.rp_filter=0
$ ip netns exec mptcp-client sysctl -w net.mptcp.enabled=1
$ ip netns exec mptcp-server sysctl -w net.mptcp.enabled=1
$ ip link add red-client netns mptcp-client type veth peer red-server \
netns mptcp-server
$ ip -n mptcp-server address add 10.0.0.1/24 dev red-server
$ ip -n mptcp-server address add 192.168.0.1/24 dev red-server
$ ip -n mptcp-client address add 10.0.0.2/24 dev red-client
$ ip -n mptcp-client address add 192.168.0.2/24 dev red-client
$ ip -n mptcp-server link set red-server up
$ ip -n mptcp-client link set red-client up
2. configure the endpoint and limit for client and server:
$ ip -n mptcp-server mptcp endpoint flush
$ ip -n mptcp-server mptcp limits set subflow 2 add_addr_accepted 2
$ ip -n mptcp-client mptcp endpoint flush
$ ip -n mptcp-client mptcp limits set subflow 2 add_addr_accepted 2
$ ip -n mptcp-client mptcp endpoint add 192.168.0.2 dev red-client id \
1 subflow
3. listen and accept on a port, such as 9999. The nc command we used
here is modified, which makes it use mptcp protocol by default.
$ ip netns exec mptcp-server nc -l -k -p 9999
4. open another *two* terminal and use each of them to connect to the
server with the following command:
$ ip netns exec mptcp-client nc 10.0.0.1 9999
Input something after connect to trigger the connection of the second
subflow. So that there are two established mptcp connections, with the
second one still unaccepted.
5. exit all the nc command, and check the tcp socket in server namespace.
And you will find that there is one tcp socket in CLOSE_WAIT state
and can't release forever.
Fix this by closing all of the unaccepted mptcp socket in
mptcp_subflow_queue_clean() with __mptcp_close().
Now, we can ensure that all unaccepted mptcp sockets will be cleaned by
__mptcp_close() before they are released, so mptcp_sock_destruct(), which
is used to clean the unaccepted mptcp socket, is not needed anymore.
The selftests for mptcp is ran for this commit, and no new failures.
Fixes: f296234c98a8 ("mptcp: Add handling of incoming MP_JOIN requests")
Fixes: 6aeed9045071 ("mptcp: fix race on unaccepted mptcp sockets")
Cc: stable@vger.kernel.org
Reviewed-by: Jiang Biao <benbjiang@tencent.com>
Reviewed-by: Mengen Sun <mengensun@tencent.com>
Acked-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Menglong Dong <imagedong@tencent.com>
Signed-off-by: Mat Martineau <mathew.j.martineau@linux.intel.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-09-27 12:31:58 -07:00
|
|
|
|
2020-02-26 10:14:47 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-19 11:45:54 -08:00
|
|
|
|
2020-11-16 10:48:09 +01:00
|
|
|
|
2020-02-26 10:14:47 +01:00
|
|
|
|
|
|
|
|
|
2020-09-24 08:29:49 +08:00
|
|
|
|
2020-01-21 16:56:21 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-08-23 17:36:59 -05:00
|
|
|
|
2020-01-21 16:56:21 -08:00
|
|
|
|
2023-06-20 18:24:18 +02:00
|
|
|
|
2020-01-21 16:56:21 -08:00
|
|
|
|
|
|
|
|
|
2020-07-28 15:12:06 -07:00
|
|
|
|
mptcp: pr_debug: add missing \n at the end
pr_debug() have been added in various places in MPTCP code to help
developers to debug some situations. With the dynamic debug feature, it
is easy to enable all or some of them, and asks users to reproduce
issues with extra debug.
Many of these pr_debug() don't end with a new line, while no 'pr_cont()'
are used in MPTCP code. So the goal was not to display multiple debug
messages on one line: they were then not missing the '\n' on purpose.
Not having the new line at the end causes these messages to be printed
with a delay, when something else needs to be printed. This issue is not
visible when many messages need to be printed, but it is annoying and
confusing when only specific messages are expected, e.g.
# echo "func mptcp_pm_add_addr_echoed +fmp" \
> /sys/kernel/debug/dynamic_debug/control
# ./mptcp_join.sh "signal address"; \
echo "$(awk '{print $1}' /proc/uptime) - end"; \
sleep 5s; \
echo "$(awk '{print $1}' /proc/uptime) - restart"; \
./mptcp_join.sh "signal address"
013 signal address
(...)
10.75 - end
15.76 - restart
013 signal address
[ 10.367935] mptcp:mptcp_pm_add_addr_echoed: MPTCP: msk=(...)
(...)
=> a delay of 5 seconds: printed with a 10.36 ts, but after 'restart'
which was printed at the 15.76 ts.
The 'Fixes' tag here below points to the first pr_debug() used without
'\n' in net/mptcp. This patch could be split in many small ones, with
different Fixes tag, but it doesn't seem worth it, because it is easy to
re-generate this patch with this simple 'sed' command:
git grep -l pr_debug -- net/mptcp |
xargs sed -i "s/\(pr_debug(\".*[^n]\)\(\"[,)]\)/\1\\\n\2/g"
So in case of conflicts, simply drop the modifications, and launch this
command.
Fixes: f870fa0b5768 ("mptcp: Add MPTCP socket stubs")
Cc: stable@vger.kernel.org
Reviewed-by: Geliang Tang <geliang@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20240826-net-mptcp-close-extra-sf-fin-v1-4-905199fe1172@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26 19:11:21 +02:00
|
|
|
|
2020-07-28 15:12:06 -07:00
|
|
|
|
|
|
|
|
|
2023-06-20 18:24:21 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-07-28 15:12:06 -07:00
|
|
|
|
mptcp: pr_debug: add missing \n at the end
pr_debug() have been added in various places in MPTCP code to help
developers to debug some situations. With the dynamic debug feature, it
is easy to enable all or some of them, and asks users to reproduce
issues with extra debug.
Many of these pr_debug() don't end with a new line, while no 'pr_cont()'
are used in MPTCP code. So the goal was not to display multiple debug
messages on one line: they were then not missing the '\n' on purpose.
Not having the new line at the end causes these messages to be printed
with a delay, when something else needs to be printed. This issue is not
visible when many messages need to be printed, but it is annoying and
confusing when only specific messages are expected, e.g.
# echo "func mptcp_pm_add_addr_echoed +fmp" \
> /sys/kernel/debug/dynamic_debug/control
# ./mptcp_join.sh "signal address"; \
echo "$(awk '{print $1}' /proc/uptime) - end"; \
sleep 5s; \
echo "$(awk '{print $1}' /proc/uptime) - restart"; \
./mptcp_join.sh "signal address"
013 signal address
(...)
10.75 - end
15.76 - restart
013 signal address
[ 10.367935] mptcp:mptcp_pm_add_addr_echoed: MPTCP: msk=(...)
(...)
=> a delay of 5 seconds: printed with a 10.36 ts, but after 'restart'
which was printed at the 15.76 ts.
The 'Fixes' tag here below points to the first pr_debug() used without
'\n' in net/mptcp. This patch could be split in many small ones, with
different Fixes tag, but it doesn't seem worth it, because it is easy to
re-generate this patch with this simple 'sed' command:
git grep -l pr_debug -- net/mptcp |
xargs sed -i "s/\(pr_debug(\".*[^n]\)\(\"[,)]\)/\1\\\n\2/g"
So in case of conflicts, simply drop the modifications, and launch this
command.
Fixes: f870fa0b5768 ("mptcp: Add MPTCP socket stubs")
Cc: stable@vger.kernel.org
Reviewed-by: Geliang Tang <geliang@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20240826-net-mptcp-close-extra-sf-fin-v1-4-905199fe1172@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26 19:11:21 +02:00
|
|
|
|
2020-07-28 15:12:06 -07:00
|
|
|
|
2023-09-16 12:52:48 +02:00
|
|
|
|
|
|
|
|
|
2020-07-28 15:12:06 -07:00
|
|
|
|
2020-01-21 16:56:21 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-12-22 13:47:22 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-06-04 01:02:17 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-09-08 16:07:06 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-12-22 13:47:22 +01:00
|
|
|
|
2024-06-04 01:02:17 +08:00
|
|
|
|
2023-12-22 13:47:22 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-07-28 15:12:04 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-12-22 13:47:23 +01:00
|
|
|
|
2020-07-28 15:12:04 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-06-20 18:24:21 +02:00
|
|
|
|
2020-11-16 10:48:09 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
mptcp: pr_debug: add missing \n at the end
pr_debug() have been added in various places in MPTCP code to help
developers to debug some situations. With the dynamic debug feature, it
is easy to enable all or some of them, and asks users to reproduce
issues with extra debug.
Many of these pr_debug() don't end with a new line, while no 'pr_cont()'
are used in MPTCP code. So the goal was not to display multiple debug
messages on one line: they were then not missing the '\n' on purpose.
Not having the new line at the end causes these messages to be printed
with a delay, when something else needs to be printed. This issue is not
visible when many messages need to be printed, but it is annoying and
confusing when only specific messages are expected, e.g.
# echo "func mptcp_pm_add_addr_echoed +fmp" \
> /sys/kernel/debug/dynamic_debug/control
# ./mptcp_join.sh "signal address"; \
echo "$(awk '{print $1}' /proc/uptime) - end"; \
sleep 5s; \
echo "$(awk '{print $1}' /proc/uptime) - restart"; \
./mptcp_join.sh "signal address"
013 signal address
(...)
10.75 - end
15.76 - restart
013 signal address
[ 10.367935] mptcp:mptcp_pm_add_addr_echoed: MPTCP: msk=(...)
(...)
=> a delay of 5 seconds: printed with a 10.36 ts, but after 'restart'
which was printed at the 15.76 ts.
The 'Fixes' tag here below points to the first pr_debug() used without
'\n' in net/mptcp. This patch could be split in many small ones, with
different Fixes tag, but it doesn't seem worth it, because it is easy to
re-generate this patch with this simple 'sed' command:
git grep -l pr_debug -- net/mptcp |
xargs sed -i "s/\(pr_debug(\".*[^n]\)\(\"[,)]\)/\1\\\n\2/g"
So in case of conflicts, simply drop the modifications, and launch this
command.
Fixes: f870fa0b5768 ("mptcp: Add MPTCP socket stubs")
Cc: stable@vger.kernel.org
Reviewed-by: Geliang Tang <geliang@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20240826-net-mptcp-close-extra-sf-fin-v1-4-905199fe1172@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26 19:11:21 +02:00
|
|
|
|
2020-11-16 10:48:09 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
mptcp: pr_debug: add missing \n at the end
pr_debug() have been added in various places in MPTCP code to help
developers to debug some situations. With the dynamic debug feature, it
is easy to enable all or some of them, and asks users to reproduce
issues with extra debug.
Many of these pr_debug() don't end with a new line, while no 'pr_cont()'
are used in MPTCP code. So the goal was not to display multiple debug
messages on one line: they were then not missing the '\n' on purpose.
Not having the new line at the end causes these messages to be printed
with a delay, when something else needs to be printed. This issue is not
visible when many messages need to be printed, but it is annoying and
confusing when only specific messages are expected, e.g.
# echo "func mptcp_pm_add_addr_echoed +fmp" \
> /sys/kernel/debug/dynamic_debug/control
# ./mptcp_join.sh "signal address"; \
echo "$(awk '{print $1}' /proc/uptime) - end"; \
sleep 5s; \
echo "$(awk '{print $1}' /proc/uptime) - restart"; \
./mptcp_join.sh "signal address"
013 signal address
(...)
10.75 - end
15.76 - restart
013 signal address
[ 10.367935] mptcp:mptcp_pm_add_addr_echoed: MPTCP: msk=(...)
(...)
=> a delay of 5 seconds: printed with a 10.36 ts, but after 'restart'
which was printed at the 15.76 ts.
The 'Fixes' tag here below points to the first pr_debug() used without
'\n' in net/mptcp. This patch could be split in many small ones, with
different Fixes tag, but it doesn't seem worth it, because it is easy to
re-generate this patch with this simple 'sed' command:
git grep -l pr_debug -- net/mptcp |
xargs sed -i "s/\(pr_debug(\".*[^n]\)\(\"[,)]\)/\1\\\n\2/g"
So in case of conflicts, simply drop the modifications, and launch this
command.
Fixes: f870fa0b5768 ("mptcp: Add MPTCP socket stubs")
Cc: stable@vger.kernel.org
Reviewed-by: Geliang Tang <geliang@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20240826-net-mptcp-close-extra-sf-fin-v1-4-905199fe1172@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26 19:11:21 +02:00
|
|
|
|
2020-11-16 10:48:09 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-06-20 18:24:21 +02:00
|
|
|
|
2020-11-16 10:48:09 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-01-21 16:56:15 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
mptcp: pr_debug: add missing \n at the end
pr_debug() have been added in various places in MPTCP code to help
developers to debug some situations. With the dynamic debug feature, it
is easy to enable all or some of them, and asks users to reproduce
issues with extra debug.
Many of these pr_debug() don't end with a new line, while no 'pr_cont()'
are used in MPTCP code. So the goal was not to display multiple debug
messages on one line: they were then not missing the '\n' on purpose.
Not having the new line at the end causes these messages to be printed
with a delay, when something else needs to be printed. This issue is not
visible when many messages need to be printed, but it is annoying and
confusing when only specific messages are expected, e.g.
# echo "func mptcp_pm_add_addr_echoed +fmp" \
> /sys/kernel/debug/dynamic_debug/control
# ./mptcp_join.sh "signal address"; \
echo "$(awk '{print $1}' /proc/uptime) - end"; \
sleep 5s; \
echo "$(awk '{print $1}' /proc/uptime) - restart"; \
./mptcp_join.sh "signal address"
013 signal address
(...)
10.75 - end
15.76 - restart
013 signal address
[ 10.367935] mptcp:mptcp_pm_add_addr_echoed: MPTCP: msk=(...)
(...)
=> a delay of 5 seconds: printed with a 10.36 ts, but after 'restart'
which was printed at the 15.76 ts.
The 'Fixes' tag here below points to the first pr_debug() used without
'\n' in net/mptcp. This patch could be split in many small ones, with
different Fixes tag, but it doesn't seem worth it, because it is easy to
re-generate this patch with this simple 'sed' command:
git grep -l pr_debug -- net/mptcp |
xargs sed -i "s/\(pr_debug(\".*[^n]\)\(\"[,)]\)/\1\\\n\2/g"
So in case of conflicts, simply drop the modifications, and launch this
command.
Fixes: f870fa0b5768 ("mptcp: Add MPTCP socket stubs")
Cc: stable@vger.kernel.org
Reviewed-by: Geliang Tang <geliang@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20240826-net-mptcp-close-extra-sf-fin-v1-4-905199fe1172@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26 19:11:21 +02:00
|
|
|
|
2020-02-04 18:12:30 +01:00
|
|
|
|
2021-02-04 15:23:30 -08:00
|
|
|
|
|
|
|
|
|
2023-09-16 12:52:48 +02:00
|
|
|
|
2025-11-24 17:50:12 +00:00
|
|
|
|
2020-11-16 10:48:09 +01:00
|
|
|
|
2023-08-21 15:25:16 -07:00
|
|
|
|
mptcp: avoid a lockdep splat when mcast group was joined
syzbot triggered following lockdep splat:
ffffffff82d2cd40 (rtnl_mutex){+.+.}, at: ip_mc_drop_socket+0x52/0x180
but task is already holding lock:
ffff8881187a2310 (sk_lock-AF_INET){+.+.}, at: mptcp_close+0x18/0x30
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (sk_lock-AF_INET){+.+.}:
lock_acquire+0xee/0x230
lock_sock_nested+0x89/0xc0
do_ip_setsockopt.isra.0+0x335/0x22f0
ip_setsockopt+0x35/0x60
tcp_setsockopt+0x5d/0x90
__sys_setsockopt+0xf3/0x190
__x64_sys_setsockopt+0x61/0x70
do_syscall_64+0x72/0x300
entry_SYSCALL_64_after_hwframe+0x49/0xbe
-> #0 (rtnl_mutex){+.+.}:
check_prevs_add+0x2b7/0x1210
__lock_acquire+0x10b6/0x1400
lock_acquire+0xee/0x230
__mutex_lock+0x120/0xc70
ip_mc_drop_socket+0x52/0x180
inet_release+0x36/0xe0
__sock_release+0xfd/0x130
__mptcp_close+0xa8/0x1f0
inet_release+0x7f/0xe0
__sock_release+0x69/0x130
sock_close+0x18/0x20
__fput+0x179/0x400
task_work_run+0xd5/0x110
do_exit+0x685/0x1510
do_group_exit+0x7e/0x170
__x64_sys_exit_group+0x28/0x30
do_syscall_64+0x72/0x300
entry_SYSCALL_64_after_hwframe+0x49/0xbe
The trigger is:
socket(AF_INET, SOCK_STREAM, 0x106 /* IPPROTO_MPTCP */) = 4
setsockopt(4, SOL_IP, MCAST_JOIN_GROUP, {gr_interface=7, gr_group={sa_family=AF_INET, sin_port=htons(20003), sin_addr=inet_addr("224.0.0.2")}}, 136) = 0
exit(0)
Which results in a call to rtnl_lock while we are holding
the parent mptcp socket lock via
mptcp_close -> lock_sock(msk) -> inet_release -> ip_mc_drop_socket -> rtnl_lock().
>From lockdep point of view we thus have both
'rtnl_lock; lock_sock' and 'lock_sock; rtnl_lock'.
Fix this by stealing the msk conn_list and doing the subflow close
without holding the msk lock.
Fixes: cec37a6e41aae7bf ("mptcp: Handle MP_CAPABLE options for outgoing connections")
Reported-by: Christoph Paasch <cpaasch@apple.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
2020-01-29 15:54:45 +01:00
|
|
|
|
2020-11-16 10:48:09 +01:00
|
|
|
|
2020-02-26 10:14:47 +01:00
|
|
|
|
2020-11-16 10:48:09 +01:00
|
|
|
|
|
|
|
|
|
2021-04-15 16:45:01 -07:00
|
|
|
|
2020-11-16 10:48:09 +01:00
|
|
|
|
|
|
|
|
|
2020-02-26 10:14:48 +01:00
|
|
|
|
2023-04-17 16:00:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-10-23 13:44:38 -07:00
|
|
|
|
2022-09-30 08:59:32 -07:00
|
|
|
|
2023-10-23 13:44:38 -07:00
|
|
|
|
2022-09-30 08:59:32 -07:00
|
|
|
|
|
|
|
|
|
2023-06-20 18:24:23 +02:00
|
|
|
|
2023-01-06 10:57:23 -08:00
|
|
|
|
2023-06-20 18:24:23 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-07-04 22:44:33 +02:00
|
|
|
|
2023-06-20 18:24:23 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-01-06 10:57:23 -08:00
|
|
|
|
|
|
|
|
|
2022-09-27 12:31:57 -07:00
|
|
|
|
2020-11-16 10:48:09 +01:00
|
|
|
|
|
|
|
|
|
2022-06-27 18:02:37 -07:00
|
|
|
|
2020-11-16 10:48:09 +01:00
|
|
|
|
2023-02-07 14:04:13 +01:00
|
|
|
|
2020-11-16 10:48:09 +01:00
|
|
|
|
2023-05-31 12:37:07 -07:00
|
|
|
|
2020-11-16 10:48:09 +01:00
|
|
|
|
|
|
|
|
|
2023-06-20 18:24:23 +02:00
|
|
|
|
2023-12-22 13:47:23 +01:00
|
|
|
|
2020-11-16 10:48:09 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-04-27 21:54:35 +02:00
|
|
|
|
|
|
|
|
|
2023-04-14 16:08:04 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-09-30 08:59:32 -07:00
|
|
|
|
2023-04-14 16:08:04 +02:00
|
|
|
|
2022-09-30 08:59:32 -07:00
|
|
|
|
2020-11-16 10:48:09 +01:00
|
|
|
|
2022-09-30 08:59:32 -07:00
|
|
|
|
2020-11-16 10:48:09 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-06-27 18:02:37 -07:00
|
|
|
|
2020-11-16 10:48:09 +01:00
|
|
|
|
net: introduce and use lock_sock_fast_nested()
Syzkaller reported a false positive deadlock involving
the nl socket lock and the subflow socket lock:
MPTCP: kernel_bind error, err=-98
============================================
WARNING: possible recursive locking detected
5.15.0-rc1-syzkaller #0 Not tainted
--------------------------------------------
syz-executor998/6520 is trying to acquire lock:
ffff8880795718a0 (k-sk_lock-AF_INET){+.+.}-{0:0}, at: mptcp_close+0x267/0x7b0 net/mptcp/protocol.c:2738
but task is already holding lock:
ffff8880787c8c60 (k-sk_lock-AF_INET){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1612 [inline]
ffff8880787c8c60 (k-sk_lock-AF_INET){+.+.}-{0:0}, at: mptcp_close+0x23/0x7b0 net/mptcp/protocol.c:2720
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(k-sk_lock-AF_INET);
lock(k-sk_lock-AF_INET);
*** DEADLOCK ***
May be due to missing lock nesting notation
3 locks held by syz-executor998/6520:
#0: ffffffff8d176c50 (cb_lock){++++}-{3:3}, at: genl_rcv+0x15/0x40 net/netlink/genetlink.c:802
#1: ffffffff8d176d08 (genl_mutex){+.+.}-{3:3}, at: genl_lock net/netlink/genetlink.c:33 [inline]
#1: ffffffff8d176d08 (genl_mutex){+.+.}-{3:3}, at: genl_rcv_msg+0x3e0/0x580 net/netlink/genetlink.c:790
#2: ffff8880787c8c60 (k-sk_lock-AF_INET){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1612 [inline]
#2: ffff8880787c8c60 (k-sk_lock-AF_INET){+.+.}-{0:0}, at: mptcp_close+0x23/0x7b0 net/mptcp/protocol.c:2720
stack backtrace:
CPU: 1 PID: 6520 Comm: syz-executor998 Not tainted 5.15.0-rc1-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
print_deadlock_bug kernel/locking/lockdep.c:2944 [inline]
check_deadlock kernel/locking/lockdep.c:2987 [inline]
validate_chain kernel/locking/lockdep.c:3776 [inline]
__lock_acquire.cold+0x149/0x3ab kernel/locking/lockdep.c:5015
lock_acquire kernel/locking/lockdep.c:5625 [inline]
lock_acquire+0x1ab/0x510 kernel/locking/lockdep.c:5590
lock_sock_fast+0x36/0x100 net/core/sock.c:3229
mptcp_close+0x267/0x7b0 net/mptcp/protocol.c:2738
inet_release+0x12e/0x280 net/ipv4/af_inet.c:431
__sock_release net/socket.c:649 [inline]
sock_release+0x87/0x1b0 net/socket.c:677
mptcp_pm_nl_create_listen_socket+0x238/0x2c0 net/mptcp/pm_netlink.c:900
mptcp_nl_cmd_add_addr+0x359/0x930 net/mptcp/pm_netlink.c:1170
genl_family_rcv_msg_doit+0x228/0x320 net/netlink/genetlink.c:731
genl_family_rcv_msg net/netlink/genetlink.c:775 [inline]
genl_rcv_msg+0x328/0x580 net/netlink/genetlink.c:792
netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2504
genl_rcv+0x24/0x40 net/netlink/genetlink.c:803
netlink_unicast_kernel net/netlink/af_netlink.c:1314 [inline]
netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1340
netlink_sendmsg+0x86d/0xdb0 net/netlink/af_netlink.c:1929
sock_sendmsg_nosec net/socket.c:704 [inline]
sock_sendmsg+0xcf/0x120 net/socket.c:724
sock_no_sendpage+0x101/0x150 net/core/sock.c:2980
kernel_sendpage.part.0+0x1a0/0x340 net/socket.c:3504
kernel_sendpage net/socket.c:3501 [inline]
sock_sendpage+0xe5/0x140 net/socket.c:1003
pipe_to_sendpage+0x2ad/0x380 fs/splice.c:364
splice_from_pipe_feed fs/splice.c:418 [inline]
__splice_from_pipe+0x43e/0x8a0 fs/splice.c:562
splice_from_pipe fs/splice.c:597 [inline]
generic_splice_sendpage+0xd4/0x140 fs/splice.c:746
do_splice_from fs/splice.c:767 [inline]
direct_splice_actor+0x110/0x180 fs/splice.c:936
splice_direct_to_actor+0x34b/0x8c0 fs/splice.c:891
do_splice_direct+0x1b3/0x280 fs/splice.c:979
do_sendfile+0xae9/0x1240 fs/read_write.c:1249
__do_sys_sendfile64 fs/read_write.c:1314 [inline]
__se_sys_sendfile64 fs/read_write.c:1300 [inline]
__x64_sys_sendfile64+0x1cc/0x210 fs/read_write.c:1300
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7f215cb69969
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 14 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffc96bb3868 EFLAGS: 00000246 ORIG_RAX: 0000000000000028
RAX: ffffffffffffffda RBX: 00007f215cbad072 RCX: 00007f215cb69969
RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000005
RBP: 0000000000000000 R08: 00007ffc96bb3a08 R09: 00007ffc96bb3a08
R10: 0000000100000002 R11: 0000000000000246 R12: 00007ffc96bb387c
R13: 431bde82d7b634db R14: 0000000000000000 R15: 0000000000000000
the problem originates from uncorrect lock annotation in the mptcp
code and is only visible since commit 2dcb96bacce3 ("net: core: Correct
the sock::sk_lock.owned lockdep annotations"), but is present since
the port-based endpoint support initial implementation.
This patch addresses the issue introducing a nested variant of
lock_sock_fast() and using it in the relevant code path.
Fixes: 1729cf186d8a ("mptcp: create the listening socket for new port")
Fixes: 2dcb96bacce3 ("net: core: Correct the sock::sk_lock.owned lockdep annotations")
Suggested-by: Thomas Gleixner <tglx@linutronix.de>
Reported-and-tested-by: syzbot+1dd53f7a89b299d59eaf@syzkaller.appspotmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
2021-09-29 11:59:17 +02:00
|
|
|
|
2020-11-16 10:48:09 +01:00
|
|
|
|
2023-02-07 14:04:13 +01:00
|
|
|
|
|
|
|
|
|
2022-06-27 18:02:37 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
mptcp: don't orphan ssk in mptcp_close()
All of the subflows of a msk will be orphaned in mptcp_close(), which
means the subflows are in DEAD state. After then, DATA_FIN will be sent,
and the other side will response with a DATA_ACK for this DATA_FIN.
However, if the other side still has pending data, the data that received
on these subflows will not be passed to the msk, as they are DEAD and
subflow_data_ready() will not be called in tcp_data_ready(). Therefore,
these data can't be acked, and they will be retransmitted again and again,
until timeout.
Fix this by setting ssk->sk_socket and ssk->sk_wq to 'NULL', instead of
orphaning the subflows in __mptcp_close(), as Paolo suggested.
Fixes: e16163b6e2b7 ("mptcp: refactor shutdown and close")
Reviewed-by: Biao Jiang <benbjiang@tencent.com>
Reviewed-by: Mengen Sun <mengensun@tencent.com>
Signed-off-by: Menglong Dong <imagedong@tencent.com>
Reviewed-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2022-11-28 16:42:37 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-16 10:48:09 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-02-07 14:04:13 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-12-22 13:47:23 +01:00
|
|
|
|
2023-02-07 14:04:13 +01:00
|
|
|
|
2020-11-16 10:48:09 +01:00
|
|
|
|
mptcp: pr_debug: add missing \n at the end
pr_debug() have been added in various places in MPTCP code to help
developers to debug some situations. With the dynamic debug feature, it
is easy to enable all or some of them, and asks users to reproduce
issues with extra debug.
Many of these pr_debug() don't end with a new line, while no 'pr_cont()'
are used in MPTCP code. So the goal was not to display multiple debug
messages on one line: they were then not missing the '\n' on purpose.
Not having the new line at the end causes these messages to be printed
with a delay, when something else needs to be printed. This issue is not
visible when many messages need to be printed, but it is annoying and
confusing when only specific messages are expected, e.g.
# echo "func mptcp_pm_add_addr_echoed +fmp" \
> /sys/kernel/debug/dynamic_debug/control
# ./mptcp_join.sh "signal address"; \
echo "$(awk '{print $1}' /proc/uptime) - end"; \
sleep 5s; \
echo "$(awk '{print $1}' /proc/uptime) - restart"; \
./mptcp_join.sh "signal address"
013 signal address
(...)
10.75 - end
15.76 - restart
013 signal address
[ 10.367935] mptcp:mptcp_pm_add_addr_echoed: MPTCP: msk=(...)
(...)
=> a delay of 5 seconds: printed with a 10.36 ts, but after 'restart'
which was printed at the 15.76 ts.
The 'Fixes' tag here below points to the first pr_debug() used without
'\n' in net/mptcp. This patch could be split in many small ones, with
different Fixes tag, but it doesn't seem worth it, because it is easy to
re-generate this patch with this simple 'sed' command:
git grep -l pr_debug -- net/mptcp |
xargs sed -i "s/\(pr_debug(\".*[^n]\)\(\"[,)]\)/\1\\\n\2/g"
So in case of conflicts, simply drop the modifications, and launch this
command.
Fixes: f870fa0b5768 ("mptcp: Add MPTCP socket stubs")
Cc: stable@vger.kernel.org
Reviewed-by: Geliang Tang <geliang@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20240826-net-mptcp-close-extra-sf-fin-v1-4-905199fe1172@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26 19:11:21 +02:00
|
|
|
|
2024-10-21 17:14:05 +02:00
|
|
|
|
2022-01-06 16:20:16 -08:00
|
|
|
|
2020-11-16 10:48:09 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-09-16 12:52:49 +02:00
|
|
|
|
2020-11-16 10:48:09 +01:00
|
|
|
|
2022-09-27 12:31:57 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-16 10:48:09 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-02-12 16:00:01 -08:00
|
|
|
|
2020-11-16 10:48:09 +01:00
|
|
|
|
2020-01-21 16:56:15 -08:00
|
|
|
|
|
|
|
|
|
2023-05-31 12:37:05 -07:00
|
|
|
|
2020-01-21 16:56:19 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-11-21 18:02:08 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-11-21 18:02:12 +01:00
|
|
|
|
2025-11-21 18:02:08 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-03-27 14:48:43 -07:00
|
|
|
|
|
|
|
|
|
2026-09-08 16:07:11 +02:00
|
|
|
|
2021-01-12 18:25:24 +01:00
|
|
|
|
|
|
|
|
|
2022-12-20 11:52:14 -08:00
|
|
|
|
|
|
|
|
|
2023-06-20 18:24:18 +02:00
|
|
|
|
2022-12-20 11:52:14 -08:00
|
|
|
|
|
|
|
|
|
2023-06-20 18:24:18 +02:00
|
|
|
|
2022-12-20 11:52:14 -08:00
|
|
|
|
2023-06-20 18:24:23 +02:00
|
|
|
|
2023-12-22 13:47:23 +01:00
|
|
|
|
2022-01-06 16:20:16 -08:00
|
|
|
|
2026-09-08 16:07:11 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-01-06 16:20:16 -08:00
|
|
|
|
2024-10-21 17:14:05 +02:00
|
|
|
|
2022-01-06 16:20:16 -08:00
|
|
|
|
2022-08-04 17:21:25 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-11-18 08:20:23 +01:00
|
|
|
|
|
|
|
|
|
2025-07-14 18:41:46 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-01-06 16:20:26 -08:00
|
|
|
|
2025-07-14 18:41:46 +02:00
|
|
|
|
|
|
|
|
|
2022-01-06 16:20:26 -08:00
|
|
|
|
2022-01-06 16:20:16 -08:00
|
|
|
|
2024-02-02 12:40:11 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-01-06 16:20:16 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-02-02 12:40:11 +01:00
|
|
|
|
2023-06-20 18:30:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-02-08 19:03:50 +01:00
|
|
|
|
2025-12-12 13:54:04 +01:00
|
|
|
|
mptcp: better mptcp-level RTT estimator
The current MPTCP-level RTT estimator has several issues. On high speed
links, the MPTCP-level receive buffer auto-tuning happens with a
frequency well above the TCP-level's one. That in turn can cause
excessive/unneeded receive buffer increase.
On such links, the initial rtt_us value is considerably higher than the
actual delay, and the current mptcp_rcv_space_adjust() updates
msk->rcvq_space.rtt_us with a period equal to the such field previous
value. If the initial rtt_us is 40ms, its first update will happen after
40ms, even if the subflows see actual RTT orders of magnitude lower.
Additionally:
- setting the msk RTT to the maximum among all the subflows RTTs makes
DRS constantly overshooting the rcvbuf size when a subflow has
considerable higher latency than the other(s).
- during unidirectional bulk transfers with multiple active subflows,
the TCP-level RTT estimator occasionally sees considerably higher
value than the real link delay, i.e. when the packet scheduler reacts
to an incoming ACK on given subflow pushing data on a different
subflow.
- currently inactive but still open subflows (i.e. switched to backup
mode) are always considered when computing the msk-level RTT.
Address the all the issues above with a more accurate RTT estimation
strategy: the MPTCP-level RTT is set to the minimum of all the subflows
actually feeding data into the MPTCP receive buffer, using a small
sliding window.
While at it, also use EWMA to compute the msk-level scaling_ratio, to
that MPTCP can avoid traversing the subflow list is
mptcp_rcv_space_adjust().
Use some care to avoid updating msk and ssk level fields too often.
Fixes: a6b118febbab ("mptcp: add receive buffer auto-tuning")
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/20260407-net-next-mptcp-reduce-rbuf-v2-1-0d1d135bf6f6@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-07 10:45:17 +02:00
|
|
|
|
2022-01-06 16:20:16 -08:00
|
|
|
|
2025-11-21 18:02:05 +01:00
|
|
|
|
|
|
|
|
|
2026-05-15 06:27:35 +02:00
|
|
|
|
2025-11-21 18:02:05 +01:00
|
|
|
|
2023-05-31 12:37:07 -07:00
|
|
|
|
2022-01-06 16:20:16 -08:00
|
|
|
|
2020-04-29 20:43:20 +02:00
|
|
|
|
2020-03-27 14:48:43 -07:00
|
|
|
|
|
|
|
|
|
2020-02-06 00:39:37 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-04-30 16:45:41 +01:00
|
|
|
|
2020-02-06 00:39:37 +01:00
|
|
|
|
2025-04-30 16:45:41 +01:00
|
|
|
|
2020-02-06 00:39:37 +01:00
|
|
|
|
2024-02-23 17:14:18 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-02-06 00:39:37 +01:00
|
|
|
|
|
|
|
|
|
2024-02-23 17:14:18 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-02-28 18:01:32 +08:00
|
|
|
|
2024-02-23 17:14:18 +01:00
|
|
|
|
2025-02-28 18:01:32 +08:00
|
|
|
|
2024-02-23 17:14:18 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-05-31 12:37:05 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-02-06 00:39:37 +01:00
|
|
|
|
2020-03-13 16:52:41 +01:00
|
|
|
|
2020-02-06 00:39:37 +01:00
|
|
|
|
2024-02-08 19:03:52 +01:00
|
|
|
|
2020-03-13 16:52:41 +01:00
|
|
|
|
2020-02-06 00:39:37 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-03-13 16:52:41 +01:00
|
|
|
|
|
|
|
|
|
2024-02-23 17:14:18 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-03-13 16:52:41 +01:00
|
|
|
|
2024-02-02 12:40:07 +01:00
|
|
|
|
2024-02-02 12:40:10 +01:00
|
|
|
|
2023-03-09 15:49:59 +01:00
|
|
|
|
2020-07-23 13:02:32 +02:00
|
|
|
|
2021-08-26 17:44:52 -07:00
|
|
|
|
2021-06-17 16:46:13 -07:00
|
|
|
|
2020-03-13 16:52:41 +01:00
|
|
|
|
2024-02-02 12:40:08 +01:00
|
|
|
|
|
|
|
|
|
2024-02-02 12:40:09 +01:00
|
|
|
|
2024-02-29 14:17:54 -08:00
|
|
|
|
2021-04-15 16:44:54 -07:00
|
|
|
|
2023-08-21 15:25:16 -07:00
|
|
|
|
2020-11-16 10:48:13 +01:00
|
|
|
|
2023-06-20 18:30:17 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-04-20 16:25:04 +02:00
|
|
|
|
2020-12-16 12:48:32 +01:00
|
|
|
|
2023-05-31 12:37:05 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-12-22 13:47:23 +01:00
|
|
|
|
2023-05-31 12:37:05 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-02-08 19:03:52 +01:00
|
|
|
|
|
|
|
|
|
2023-05-31 12:37:05 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-02-03 19:41:18 +01:00
|
|
|
|
2024-02-08 19:03:52 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-03-13 16:52:41 +01:00
|
|
|
|
|
|
|
|
|
2023-03-09 15:49:59 +01:00
|
|
|
|
2020-02-06 00:39:37 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-01-21 16:56:20 -08:00
|
|
|
|
|
|
|
|
|
2020-01-29 15:54:43 +01:00
|
|
|
|
|
|
|
|
|
2023-08-11 17:57:26 +02:00
|
|
|
|
|
|
|
|
|
2025-11-18 08:20:23 +01:00
|
|
|
|
2020-03-27 14:48:45 -07:00
|
|
|
|
2020-01-21 16:56:20 -08:00
|
|
|
|
|
|
|
|
|
2020-11-27 11:10:27 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-01-06 16:20:26 -08:00
|
|
|
|
2020-11-27 11:10:27 +01:00
|
|
|
|
|
|
|
|
|
2020-12-16 12:48:34 +01:00
|
|
|
|
2020-11-27 11:10:27 +01:00
|
|
|
|
2022-11-10 15:23:19 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-01-06 16:20:26 -08:00
|
|
|
|
2020-11-27 11:10:27 +01:00
|
|
|
|
|
|
|
|
|
2022-01-06 16:20:26 -08:00
|
|
|
|
|
|
|
|
|
2025-11-21 18:02:13 +01:00
|
|
|
|
2022-01-06 16:20:26 -08:00
|
|
|
|
2020-11-27 11:10:23 +01:00
|
|
|
|
2020-02-26 10:14:52 +01:00
|
|
|
|
2022-01-06 16:20:26 -08:00
|
|
|
|
2020-02-26 10:14:52 +01:00
|
|
|
|
2022-01-06 16:20:26 -08:00
|
|
|
|
2026-08-07 15:49:05 +02:00
|
|
|
|
2021-03-26 11:26:30 -07:00
|
|
|
|
2022-01-06 16:20:26 -08:00
|
|
|
|
2024-02-08 19:03:49 +01:00
|
|
|
|
2025-11-21 18:02:13 +01:00
|
|
|
|
|
|
|
|
|
2023-06-20 18:24:20 +02:00
|
|
|
|
2025-11-21 18:02:13 +01:00
|
|
|
|
|
|
|
|
|
2021-03-04 13:32:14 -08:00
|
|
|
|
|
|
|
|
|
2023-06-20 18:24:20 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-03-04 13:32:14 -08:00
|
|
|
|
2020-11-27 11:10:27 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-01-06 16:20:26 -08:00
|
|
|
|
2020-11-27 11:10:27 +01:00
|
|
|
|
2023-06-20 18:24:20 +02:00
|
|
|
|
2022-01-06 16:20:25 -08:00
|
|
|
|
2023-06-20 18:24:20 +02:00
|
|
|
|
2021-03-12 10:41:12 +03:00
|
|
|
|
2021-03-04 13:32:14 -08:00
|
|
|
|
2021-03-26 11:26:30 -07:00
|
|
|
|
|
|
|
|
|
2025-11-21 18:02:13 +01:00
|
|
|
|
2025-02-18 19:36:14 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-03-04 13:32:14 -08:00
|
|
|
|
|
|
|
|
|
2020-11-27 11:10:27 +01:00
|
|
|
|
|
|
|
|
|
2026-08-07 15:49:05 +02:00
|
|
|
|
|
|
|
|
|
2021-03-04 13:32:14 -08:00
|
|
|
|
2022-01-06 16:20:26 -08:00
|
|
|
|
2021-03-04 13:32:15 -08:00
|
|
|
|
2023-08-03 07:24:38 +00:00
|
|
|
|
2023-12-15 17:04:25 +01:00
|
|
|
|
2023-11-14 00:16:14 +01:00
|
|
|
|
|
|
|
|
|
2022-04-08 12:45:54 -07:00
|
|
|
|
2023-12-15 17:04:25 +01:00
|
|
|
|
|
|
|
|
|
2022-04-08 12:45:54 -07:00
|
|
|
|
|
|
|
|
|
2023-10-23 13:44:42 -07:00
|
|
|
|
|
|
|
|
|
2022-04-08 12:45:54 -07:00
|
|
|
|
2020-02-26 10:14:52 +01:00
|
|
|
|
|
|
|
|
|
2021-11-19 15:27:55 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-09-08 16:07:15 +02:00
|
|
|
|
2021-11-19 15:27:55 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-10-02 17:30:42 +00:00
|
|
|
|
|
|
|
|
|
2021-11-19 15:27:55 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-10-04 13:38:11 -07:00
|
|
|
|
2021-01-20 15:39:14 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-10-04 13:38:11 -07:00
|
|
|
|
2021-11-19 15:27:55 +01:00
|
|
|
|
|
|
|
|
|
2022-11-10 15:23:19 -08:00
|
|
|
|
2021-11-19 15:27:55 +01:00
|
|
|
|
2022-01-06 16:20:26 -08:00
|
|
|
|
2021-11-19 15:27:55 +01:00
|
|
|
|
|
|
|
|
|
2023-10-23 13:44:42 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-10-04 13:38:11 -07:00
|
|
|
|
2021-11-19 15:27:55 +01:00
|
|
|
|
2021-01-20 15:39:14 +01:00
|
|
|
|
|
|
|
|
|
2020-06-26 19:30:00 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-06-05 09:15:42 +02:00
|
|
|
|
2020-06-26 19:30:00 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-01-21 16:56:18 -08:00
|
|
|
|
2020-01-21 16:56:15 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
mptcp: pr_debug: add missing \n at the end
pr_debug() have been added in various places in MPTCP code to help
developers to debug some situations. With the dynamic debug feature, it
is easy to enable all or some of them, and asks users to reproduce
issues with extra debug.
Many of these pr_debug() don't end with a new line, while no 'pr_cont()'
are used in MPTCP code. So the goal was not to display multiple debug
messages on one line: they were then not missing the '\n' on purpose.
Not having the new line at the end causes these messages to be printed
with a delay, when something else needs to be printed. This issue is not
visible when many messages need to be printed, but it is annoying and
confusing when only specific messages are expected, e.g.
# echo "func mptcp_pm_add_addr_echoed +fmp" \
> /sys/kernel/debug/dynamic_debug/control
# ./mptcp_join.sh "signal address"; \
echo "$(awk '{print $1}' /proc/uptime) - end"; \
sleep 5s; \
echo "$(awk '{print $1}' /proc/uptime) - restart"; \
./mptcp_join.sh "signal address"
013 signal address
(...)
10.75 - end
15.76 - restart
013 signal address
[ 10.367935] mptcp:mptcp_pm_add_addr_echoed: MPTCP: msk=(...)
(...)
=> a delay of 5 seconds: printed with a 10.36 ts, but after 'restart'
which was printed at the 15.76 ts.
The 'Fixes' tag here below points to the first pr_debug() used without
'\n' in net/mptcp. This patch could be split in many small ones, with
different Fixes tag, but it doesn't seem worth it, because it is easy to
re-generate this patch with this simple 'sed' command:
git grep -l pr_debug -- net/mptcp |
xargs sed -i "s/\(pr_debug(\".*[^n]\)\(\"[,)]\)/\1\\\n\2/g"
So in case of conflicts, simply drop the modifications, and launch this
command.
Fixes: f870fa0b5768 ("mptcp: Add MPTCP socket stubs")
Cc: stable@vger.kernel.org
Reviewed-by: Geliang Tang <geliang@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20240826-net-mptcp-close-extra-sf-fin-v1-4-905199fe1172@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26 19:11:21 +02:00
|
|
|
|
2023-08-11 17:57:16 +02:00
|
|
|
|
2020-01-21 16:56:18 -08:00
|
|
|
|
2020-01-21 16:56:15 -08:00
|
|
|
|
2023-08-11 17:57:16 +02:00
|
|
|
|
2020-01-21 16:56:18 -08:00
|
|
|
|
2020-01-21 16:56:15 -08:00
|
|
|
|
2020-01-21 16:56:18 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-01-21 16:56:15 -08:00
|
|
|
|
2020-01-21 16:56:18 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
mptcp: pr_debug: add missing \n at the end
pr_debug() have been added in various places in MPTCP code to help
developers to debug some situations. With the dynamic debug feature, it
is easy to enable all or some of them, and asks users to reproduce
issues with extra debug.
Many of these pr_debug() don't end with a new line, while no 'pr_cont()'
are used in MPTCP code. So the goal was not to display multiple debug
messages on one line: they were then not missing the '\n' on purpose.
Not having the new line at the end causes these messages to be printed
with a delay, when something else needs to be printed. This issue is not
visible when many messages need to be printed, but it is annoying and
confusing when only specific messages are expected, e.g.
# echo "func mptcp_pm_add_addr_echoed +fmp" \
> /sys/kernel/debug/dynamic_debug/control
# ./mptcp_join.sh "signal address"; \
echo "$(awk '{print $1}' /proc/uptime) - end"; \
sleep 5s; \
echo "$(awk '{print $1}' /proc/uptime) - restart"; \
./mptcp_join.sh "signal address"
013 signal address
(...)
10.75 - end
15.76 - restart
013 signal address
[ 10.367935] mptcp:mptcp_pm_add_addr_echoed: MPTCP: msk=(...)
(...)
=> a delay of 5 seconds: printed with a 10.36 ts, but after 'restart'
which was printed at the 15.76 ts.
The 'Fixes' tag here below points to the first pr_debug() used without
'\n' in net/mptcp. This patch could be split in many small ones, with
different Fixes tag, but it doesn't seem worth it, because it is easy to
re-generate this patch with this simple 'sed' command:
git grep -l pr_debug -- net/mptcp |
xargs sed -i "s/\(pr_debug(\".*[^n]\)\(\"[,)]\)/\1\\\n\2/g"
So in case of conflicts, simply drop the modifications, and launch this
command.
Fixes: f870fa0b5768 ("mptcp: Add MPTCP socket stubs")
Cc: stable@vger.kernel.org
Reviewed-by: Geliang Tang <geliang@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20240826-net-mptcp-close-extra-sf-fin-v1-4-905199fe1172@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26 19:11:21 +02:00
|
|
|
|
2020-01-21 16:56:24 -08:00
|
|
|
|
2022-11-25 23:29:49 +01:00
|
|
|
|
2020-01-21 16:56:24 -08:00
|
|
|
|
2020-01-21 16:56:23 -08:00
|
|
|
|
2020-01-21 16:56:18 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-02-03 19:41:18 +01:00
|
|
|
|
2020-03-27 14:48:38 -07:00
|
|
|
|
2021-02-12 15:59:58 -08:00
|
|
|
|
2020-01-21 16:56:15 -08:00
|
|
|
|
|
|
|
|
|
2021-01-20 15:39:10 +01:00
|
|
|
|
2020-01-21 16:56:19 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-11-21 18:02:02 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-11-21 18:02:03 +01:00
|
|
|
|
2025-11-21 18:02:02 +01:00
|
|
|
|
2025-11-21 18:02:03 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-11-21 18:02:02 +01:00
|
|
|
|
|
|
|
|
|
2020-11-16 10:48:09 +01:00
|
|
|
|
2020-03-27 14:48:39 -07:00
|
|
|
|
2020-11-16 10:48:09 +01:00
|
|
|
|
2020-03-27 14:48:39 -07:00
|
|
|
|
|
|
|
|
|
2022-01-06 16:20:25 -08:00
|
|
|
|
2020-03-27 14:48:39 -07:00
|
|
|
|
mptcp: pr_debug: add missing \n at the end
pr_debug() have been added in various places in MPTCP code to help
developers to debug some situations. With the dynamic debug feature, it
is easy to enable all or some of them, and asks users to reproduce
issues with extra debug.
Many of these pr_debug() don't end with a new line, while no 'pr_cont()'
are used in MPTCP code. So the goal was not to display multiple debug
messages on one line: they were then not missing the '\n' on purpose.
Not having the new line at the end causes these messages to be printed
with a delay, when something else needs to be printed. This issue is not
visible when many messages need to be printed, but it is annoying and
confusing when only specific messages are expected, e.g.
# echo "func mptcp_pm_add_addr_echoed +fmp" \
> /sys/kernel/debug/dynamic_debug/control
# ./mptcp_join.sh "signal address"; \
echo "$(awk '{print $1}' /proc/uptime) - end"; \
sleep 5s; \
echo "$(awk '{print $1}' /proc/uptime) - restart"; \
./mptcp_join.sh "signal address"
013 signal address
(...)
10.75 - end
15.76 - restart
013 signal address
[ 10.367935] mptcp:mptcp_pm_add_addr_echoed: MPTCP: msk=(...)
(...)
=> a delay of 5 seconds: printed with a 10.36 ts, but after 'restart'
which was printed at the 15.76 ts.
The 'Fixes' tag here below points to the first pr_debug() used without
'\n' in net/mptcp. This patch could be split in many small ones, with
different Fixes tag, but it doesn't seem worth it, because it is easy to
re-generate this patch with this simple 'sed' command:
git grep -l pr_debug -- net/mptcp |
xargs sed -i "s/\(pr_debug(\".*[^n]\)\(\"[,)]\)/\1\\\n\2/g"
So in case of conflicts, simply drop the modifications, and launch this
command.
Fixes: f870fa0b5768 ("mptcp: Add MPTCP socket stubs")
Cc: stable@vger.kernel.org
Reviewed-by: Geliang Tang <geliang@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20240826-net-mptcp-close-extra-sf-fin-v1-4-905199fe1172@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26 19:11:21 +02:00
|
|
|
|
2020-03-27 14:48:39 -07:00
|
|
|
|
|
|
|
|
|
2021-04-01 16:19:44 -07:00
|
|
|
|
2026-08-12 16:55:40 +02:00
|
|
|
|
2021-04-01 16:19:44 -07:00
|
|
|
|
2020-03-27 14:48:39 -07:00
|
|
|
|
2021-04-01 16:19:44 -07:00
|
|
|
|
2020-03-27 14:48:39 -07:00
|
|
|
|
2025-11-21 18:02:02 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-05-31 12:37:08 -07:00
|
|
|
|
2025-07-14 18:41:44 +02:00
|
|
|
|
2025-07-14 18:41:45 +02:00
|
|
|
|
2025-07-14 18:41:44 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-05-31 12:37:08 -07:00
|
|
|
|
2025-07-14 18:41:44 +02:00
|
|
|
|
2023-10-23 13:44:42 -07:00
|
|
|
|
2023-05-31 12:37:08 -07:00
|
|
|
|
|
|
|
|
|
2020-03-27 14:48:39 -07:00
|
|
|
|
2025-04-13 11:34:36 +02:00
|
|
|
|
|
|
|
|
|
2022-01-06 16:20:25 -08:00
|
|
|
|
2025-04-13 11:34:36 +02:00
|
|
|
|
2020-05-29 17:43:30 +02:00
|
|
|
|
2023-05-31 12:37:08 -07:00
|
|
|
|
2022-01-06 16:20:25 -08:00
|
|
|
|
2020-05-29 17:43:30 +02:00
|
|
|
|
2022-01-06 16:20:25 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-11-21 18:02:02 +01:00
|
|
|
|
2022-01-06 16:20:25 -08:00
|
|
|
|
|
|
|
|
|
2020-11-16 10:48:09 +01:00
|
|
|
|
2022-01-06 16:20:25 -08:00
|
|
|
|
2022-01-06 16:20:26 -08:00
|
|
|
|
2025-11-21 18:02:02 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-16 10:48:09 +01:00
|
|
|
|
2022-01-06 16:20:25 -08:00
|
|
|
|
|
|
|
|
|
2021-04-01 16:19:44 -07:00
|
|
|
|
2026-07-22 00:14:38 +02:00
|
|
|
|
2022-01-06 16:20:25 -08:00
|
|
|
|
2021-04-01 16:19:44 -07:00
|
|
|
|
2020-05-29 17:43:30 +02:00
|
|
|
|
2021-04-01 16:19:44 -07:00
|
|
|
|
2020-05-29 17:43:30 +02:00
|
|
|
|
|
|
|
|
|
2020-03-27 14:48:39 -07:00
|
|
|
|
|
|
|
|
|
2021-01-12 18:25:24 +01:00
|
|
|
|
|
|
|
|
|
mptcp: pr_debug: add missing \n at the end
pr_debug() have been added in various places in MPTCP code to help
developers to debug some situations. With the dynamic debug feature, it
is easy to enable all or some of them, and asks users to reproduce
issues with extra debug.
Many of these pr_debug() don't end with a new line, while no 'pr_cont()'
are used in MPTCP code. So the goal was not to display multiple debug
messages on one line: they were then not missing the '\n' on purpose.
Not having the new line at the end causes these messages to be printed
with a delay, when something else needs to be printed. This issue is not
visible when many messages need to be printed, but it is annoying and
confusing when only specific messages are expected, e.g.
# echo "func mptcp_pm_add_addr_echoed +fmp" \
> /sys/kernel/debug/dynamic_debug/control
# ./mptcp_join.sh "signal address"; \
echo "$(awk '{print $1}' /proc/uptime) - end"; \
sleep 5s; \
echo "$(awk '{print $1}' /proc/uptime) - restart"; \
./mptcp_join.sh "signal address"
013 signal address
(...)
10.75 - end
15.76 - restart
013 signal address
[ 10.367935] mptcp:mptcp_pm_add_addr_echoed: MPTCP: msk=(...)
(...)
=> a delay of 5 seconds: printed with a 10.36 ts, but after 'restart'
which was printed at the 15.76 ts.
The 'Fixes' tag here below points to the first pr_debug() used without
'\n' in net/mptcp. This patch could be split in many small ones, with
different Fixes tag, but it doesn't seem worth it, because it is easy to
re-generate this patch with this simple 'sed' command:
git grep -l pr_debug -- net/mptcp |
xargs sed -i "s/\(pr_debug(\".*[^n]\)\(\"[,)]\)/\1\\\n\2/g"
So in case of conflicts, simply drop the modifications, and launch this
command.
Fixes: f870fa0b5768 ("mptcp: Add MPTCP socket stubs")
Cc: stable@vger.kernel.org
Reviewed-by: Geliang Tang <geliang@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20240826-net-mptcp-close-extra-sf-fin-v1-4-905199fe1172@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26 19:11:21 +02:00
|
|
|
|
2021-01-12 18:25:24 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-12-03 14:35:34 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-02-24 16:52:57 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-12-03 14:35:34 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
net: ioctl: Use kernel memory on protocol ioctl callbacks
Most of the ioctls to net protocols operates directly on userspace
argument (arg). Usually doing get_user()/put_user() directly in the
ioctl callback. This is not flexible, because it is hard to reuse these
functions without passing userspace buffers.
Change the "struct proto" ioctls to avoid touching userspace memory and
operate on kernel buffers, i.e., all protocol's ioctl callbacks is
adapted to operate on a kernel memory other than on userspace (so, no
more {put,get}_user() and friends being called in the ioctl callback).
This changes the "struct proto" ioctl format in the following way:
int (*ioctl)(struct sock *sk, int cmd,
- unsigned long arg);
+ int *karg);
(Important to say that this patch does not touch the "struct proto_ops"
protocols)
So, the "karg" argument, which is passed to the ioctl callback, is a
pointer allocated to kernel space memory (inside a function wrapper).
This buffer (karg) may contain input argument (copied from userspace in
a prep function) and it might return a value/buffer, which is copied
back to userspace if necessary. There is not one-size-fits-all format
(that is I am using 'may' above), but basically, there are three type of
ioctls:
1) Do not read from userspace, returns a result to userspace
2) Read an input parameter from userspace, and does not return anything
to userspace
3) Read an input from userspace, and return a buffer to userspace.
The default case (1) (where no input parameter is given, and an "int" is
returned to userspace) encompasses more than 90% of the cases, but there
are two other exceptions. Here is a list of exceptions:
* Protocol RAW:
* cmd = SIOCGETVIFCNT:
* input and output = struct sioc_vif_req
* cmd = SIOCGETSGCNT
* input and output = struct sioc_sg_req
* Explanation: for the SIOCGETVIFCNT case, userspace passes the input
argument, which is struct sioc_vif_req. Then the callback populates
the struct, which is copied back to userspace.
* Protocol RAW6:
* cmd = SIOCGETMIFCNT_IN6
* input and output = struct sioc_mif_req6
* cmd = SIOCGETSGCNT_IN6
* input and output = struct sioc_sg_req6
* Protocol PHONET:
* cmd == SIOCPNADDRESOURCE | SIOCPNDELRESOURCE
* input int (4 bytes)
* Nothing is copied back to userspace.
For the exception cases, functions sock_sk_ioctl_inout() will
copy the userspace input, and copy it back to kernel space.
The wrapper that prepare the buffer and put the buffer back to user is
sk_ioctl(), so, instead of calling sk->sk_prot->ioctl(), the callee now
calls sk_ioctl(), which will handle all cases.
Signed-off-by: Breno Leitao <leitao@debian.org>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com>
Link: https://lore.kernel.org/r/20230609152800.830401-1-leitao@debian.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-06-09 08:27:42 -07:00
|
|
|
|
2021-12-03 14:35:34 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-11-21 18:02:13 +01:00
|
|
|
|
2025-02-18 19:36:14 +01:00
|
|
|
|
net: ioctl: Use kernel memory on protocol ioctl callbacks
Most of the ioctls to net protocols operates directly on userspace
argument (arg). Usually doing get_user()/put_user() directly in the
ioctl callback. This is not flexible, because it is hard to reuse these
functions without passing userspace buffers.
Change the "struct proto" ioctls to avoid touching userspace memory and
operate on kernel buffers, i.e., all protocol's ioctl callbacks is
adapted to operate on a kernel memory other than on userspace (so, no
more {put,get}_user() and friends being called in the ioctl callback).
This changes the "struct proto" ioctl format in the following way:
int (*ioctl)(struct sock *sk, int cmd,
- unsigned long arg);
+ int *karg);
(Important to say that this patch does not touch the "struct proto_ops"
protocols)
So, the "karg" argument, which is passed to the ioctl callback, is a
pointer allocated to kernel space memory (inside a function wrapper).
This buffer (karg) may contain input argument (copied from userspace in
a prep function) and it might return a value/buffer, which is copied
back to userspace if necessary. There is not one-size-fits-all format
(that is I am using 'may' above), but basically, there are three type of
ioctls:
1) Do not read from userspace, returns a result to userspace
2) Read an input parameter from userspace, and does not return anything
to userspace
3) Read an input from userspace, and return a buffer to userspace.
The default case (1) (where no input parameter is given, and an "int" is
returned to userspace) encompasses more than 90% of the cases, but there
are two other exceptions. Here is a list of exceptions:
* Protocol RAW:
* cmd = SIOCGETVIFCNT:
* input and output = struct sioc_vif_req
* cmd = SIOCGETSGCNT
* input and output = struct sioc_sg_req
* Explanation: for the SIOCGETVIFCNT case, userspace passes the input
argument, which is struct sioc_vif_req. Then the callback populates
the struct, which is copied back to userspace.
* Protocol RAW6:
* cmd = SIOCGETMIFCNT_IN6
* input and output = struct sioc_mif_req6
* cmd = SIOCGETSGCNT_IN6
* input and output = struct sioc_sg_req6
* Protocol PHONET:
* cmd == SIOCPNADDRESOURCE | SIOCPNDELRESOURCE
* input int (4 bytes)
* Nothing is copied back to userspace.
For the exception cases, functions sock_sk_ioctl_inout() will
copy the userspace input, and copy it back to kernel space.
The wrapper that prepare the buffer and put the buffer back to user is
sk_ioctl(), so, instead of calling sk->sk_prot->ioctl(), the callee now
calls sk_ioctl(), which will handle all cases.
Signed-off-by: Breno Leitao <leitao@debian.org>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com>
Link: https://lore.kernel.org/r/20230609152800.830401-1-leitao@debian.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-06-09 08:27:42 -07:00
|
|
|
|
2021-12-03 14:35:34 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
net: ioctl: Use kernel memory on protocol ioctl callbacks
Most of the ioctls to net protocols operates directly on userspace
argument (arg). Usually doing get_user()/put_user() directly in the
ioctl callback. This is not flexible, because it is hard to reuse these
functions without passing userspace buffers.
Change the "struct proto" ioctls to avoid touching userspace memory and
operate on kernel buffers, i.e., all protocol's ioctl callbacks is
adapted to operate on a kernel memory other than on userspace (so, no
more {put,get}_user() and friends being called in the ioctl callback).
This changes the "struct proto" ioctl format in the following way:
int (*ioctl)(struct sock *sk, int cmd,
- unsigned long arg);
+ int *karg);
(Important to say that this patch does not touch the "struct proto_ops"
protocols)
So, the "karg" argument, which is passed to the ioctl callback, is a
pointer allocated to kernel space memory (inside a function wrapper).
This buffer (karg) may contain input argument (copied from userspace in
a prep function) and it might return a value/buffer, which is copied
back to userspace if necessary. There is not one-size-fits-all format
(that is I am using 'may' above), but basically, there are three type of
ioctls:
1) Do not read from userspace, returns a result to userspace
2) Read an input parameter from userspace, and does not return anything
to userspace
3) Read an input from userspace, and return a buffer to userspace.
The default case (1) (where no input parameter is given, and an "int" is
returned to userspace) encompasses more than 90% of the cases, but there
are two other exceptions. Here is a list of exceptions:
* Protocol RAW:
* cmd = SIOCGETVIFCNT:
* input and output = struct sioc_vif_req
* cmd = SIOCGETSGCNT
* input and output = struct sioc_sg_req
* Explanation: for the SIOCGETVIFCNT case, userspace passes the input
argument, which is struct sioc_vif_req. Then the callback populates
the struct, which is copied back to userspace.
* Protocol RAW6:
* cmd = SIOCGETMIFCNT_IN6
* input and output = struct sioc_mif_req6
* cmd = SIOCGETSGCNT_IN6
* input and output = struct sioc_sg_req6
* Protocol PHONET:
* cmd == SIOCPNADDRESOURCE | SIOCPNDELRESOURCE
* input int (4 bytes)
* Nothing is copied back to userspace.
For the exception cases, functions sock_sk_ioctl_inout() will
copy the userspace input, and copy it back to kernel space.
The wrapper that prepare the buffer and put the buffer back to user is
sk_ioctl(), so, instead of calling sk->sk_prot->ioctl(), the callee now
calls sk_ioctl(), which will handle all cases.
Signed-off-by: Breno Leitao <leitao@debian.org>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com>
Link: https://lore.kernel.org/r/20230609152800.830401-1-leitao@debian.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-06-09 08:27:42 -07:00
|
|
|
|
2021-12-03 14:35:34 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
net: ioctl: Use kernel memory on protocol ioctl callbacks
Most of the ioctls to net protocols operates directly on userspace
argument (arg). Usually doing get_user()/put_user() directly in the
ioctl callback. This is not flexible, because it is hard to reuse these
functions without passing userspace buffers.
Change the "struct proto" ioctls to avoid touching userspace memory and
operate on kernel buffers, i.e., all protocol's ioctl callbacks is
adapted to operate on a kernel memory other than on userspace (so, no
more {put,get}_user() and friends being called in the ioctl callback).
This changes the "struct proto" ioctl format in the following way:
int (*ioctl)(struct sock *sk, int cmd,
- unsigned long arg);
+ int *karg);
(Important to say that this patch does not touch the "struct proto_ops"
protocols)
So, the "karg" argument, which is passed to the ioctl callback, is a
pointer allocated to kernel space memory (inside a function wrapper).
This buffer (karg) may contain input argument (copied from userspace in
a prep function) and it might return a value/buffer, which is copied
back to userspace if necessary. There is not one-size-fits-all format
(that is I am using 'may' above), but basically, there are three type of
ioctls:
1) Do not read from userspace, returns a result to userspace
2) Read an input parameter from userspace, and does not return anything
to userspace
3) Read an input from userspace, and return a buffer to userspace.
The default case (1) (where no input parameter is given, and an "int" is
returned to userspace) encompasses more than 90% of the cases, but there
are two other exceptions. Here is a list of exceptions:
* Protocol RAW:
* cmd = SIOCGETVIFCNT:
* input and output = struct sioc_vif_req
* cmd = SIOCGETSGCNT
* input and output = struct sioc_sg_req
* Explanation: for the SIOCGETVIFCNT case, userspace passes the input
argument, which is struct sioc_vif_req. Then the callback populates
the struct, which is copied back to userspace.
* Protocol RAW6:
* cmd = SIOCGETMIFCNT_IN6
* input and output = struct sioc_mif_req6
* cmd = SIOCGETSGCNT_IN6
* input and output = struct sioc_sg_req6
* Protocol PHONET:
* cmd == SIOCPNADDRESOURCE | SIOCPNDELRESOURCE
* input int (4 bytes)
* Nothing is copied back to userspace.
For the exception cases, functions sock_sk_ioctl_inout() will
copy the userspace input, and copy it back to kernel space.
The wrapper that prepare the buffer and put the buffer back to user is
sk_ioctl(), so, instead of calling sk->sk_prot->ioctl(), the callee now
calls sk_ioctl(), which will handle all cases.
Signed-off-by: Breno Leitao <leitao@debian.org>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com>
Link: https://lore.kernel.org/r/20230609152800.830401-1-leitao@debian.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-06-09 08:27:42 -07:00
|
|
|
|
2021-12-03 14:35:34 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
net: ioctl: Use kernel memory on protocol ioctl callbacks
Most of the ioctls to net protocols operates directly on userspace
argument (arg). Usually doing get_user()/put_user() directly in the
ioctl callback. This is not flexible, because it is hard to reuse these
functions without passing userspace buffers.
Change the "struct proto" ioctls to avoid touching userspace memory and
operate on kernel buffers, i.e., all protocol's ioctl callbacks is
adapted to operate on a kernel memory other than on userspace (so, no
more {put,get}_user() and friends being called in the ioctl callback).
This changes the "struct proto" ioctl format in the following way:
int (*ioctl)(struct sock *sk, int cmd,
- unsigned long arg);
+ int *karg);
(Important to say that this patch does not touch the "struct proto_ops"
protocols)
So, the "karg" argument, which is passed to the ioctl callback, is a
pointer allocated to kernel space memory (inside a function wrapper).
This buffer (karg) may contain input argument (copied from userspace in
a prep function) and it might return a value/buffer, which is copied
back to userspace if necessary. There is not one-size-fits-all format
(that is I am using 'may' above), but basically, there are three type of
ioctls:
1) Do not read from userspace, returns a result to userspace
2) Read an input parameter from userspace, and does not return anything
to userspace
3) Read an input from userspace, and return a buffer to userspace.
The default case (1) (where no input parameter is given, and an "int" is
returned to userspace) encompasses more than 90% of the cases, but there
are two other exceptions. Here is a list of exceptions:
* Protocol RAW:
* cmd = SIOCGETVIFCNT:
* input and output = struct sioc_vif_req
* cmd = SIOCGETSGCNT
* input and output = struct sioc_sg_req
* Explanation: for the SIOCGETVIFCNT case, userspace passes the input
argument, which is struct sioc_vif_req. Then the callback populates
the struct, which is copied back to userspace.
* Protocol RAW6:
* cmd = SIOCGETMIFCNT_IN6
* input and output = struct sioc_mif_req6
* cmd = SIOCGETSGCNT_IN6
* input and output = struct sioc_sg_req6
* Protocol PHONET:
* cmd == SIOCPNADDRESOURCE | SIOCPNDELRESOURCE
* input int (4 bytes)
* Nothing is copied back to userspace.
For the exception cases, functions sock_sk_ioctl_inout() will
copy the userspace input, and copy it back to kernel space.
The wrapper that prepare the buffer and put the buffer back to user is
sk_ioctl(), so, instead of calling sk->sk_prot->ioctl(), the callee now
calls sk_ioctl(), which will handle all cases.
Signed-off-by: Breno Leitao <leitao@debian.org>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com>
Link: https://lore.kernel.org/r/20230609152800.830401-1-leitao@debian.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-06-09 08:27:42 -07:00
|
|
|
|
2021-12-03 14:35:34 -08:00
|
|
|
|
|
|
|
|
|
2025-11-03 16:26:13 -08:00
|
|
|
|
|
|
|
|
|
2022-10-21 15:58:55 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-08-11 17:57:15 +02:00
|
|
|
|
2022-10-21 15:58:55 -07:00
|
|
|
|
2023-08-11 17:57:25 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-10-21 15:58:55 -07:00
|
|
|
|
2026-09-08 16:07:06 +02:00
|
|
|
|
2023-12-22 13:47:23 +01:00
|
|
|
|
2023-08-11 17:57:15 +02:00
|
|
|
|
2022-10-21 15:58:55 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-08-11 17:57:15 +02:00
|
|
|
|
2025-07-23 16:32:23 +02:00
|
|
|
|
2022-10-21 15:58:55 -07:00
|
|
|
|
2024-09-09 22:09:23 +02:00
|
|
|
|
2025-07-23 16:32:23 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-10-21 15:58:55 -07:00
|
|
|
|
2024-04-29 20:00:31 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-06-07 17:01:48 +02:00
|
|
|
|
2022-10-21 15:58:55 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-08-11 17:57:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-08-16 08:15:45 +00:00
|
|
|
|
2023-08-11 17:57:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-10-21 15:58:55 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-08-11 17:57:15 +02:00
|
|
|
|
2023-08-11 17:57:14 +02:00
|
|
|
|
|
|
|
|
|
2023-12-22 13:47:23 +01:00
|
|
|
|
2022-10-21 15:58:55 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-08-11 17:57:15 +02:00
|
|
|
|
2023-05-31 12:37:03 -07:00
|
|
|
|
2022-10-21 15:58:55 -07:00
|
|
|
|
|
|
|
|
|
2020-01-21 16:56:15 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-10-21 15:58:55 -07:00
|
|
|
|
2020-03-27 14:48:43 -07:00
|
|
|
|
2020-01-21 16:56:15 -08:00
|
|
|
|
2020-01-21 16:56:22 -08:00
|
|
|
|
|
|
|
|
|
2021-01-12 18:25:24 +01:00
|
|
|
|
2020-01-21 16:56:20 -08:00
|
|
|
|
2020-01-21 16:56:15 -08:00
|
|
|
|
2021-12-03 14:35:34 -08:00
|
|
|
|
2020-01-21 16:56:15 -08:00
|
|
|
|
2020-02-26 10:14:52 +01:00
|
|
|
|
2020-06-26 19:30:00 +02:00
|
|
|
|
|
|
|
|
|
2020-01-21 16:56:18 -08:00
|
|
|
|
2024-03-01 18:43:46 +01:00
|
|
|
|
2020-03-27 14:48:45 -07:00
|
|
|
|
2022-06-08 23:34:08 -07:00
|
|
|
|
2025-06-30 09:35:39 +00:00
|
|
|
|
2022-06-08 23:34:08 -07:00
|
|
|
|
|
|
|
|
|
2020-03-27 14:48:45 -07:00
|
|
|
|
|
|
|
|
|
2020-11-08 19:49:59 +01:00
|
|
|
|
2020-03-27 14:48:45 -07:00
|
|
|
|
2020-01-21 16:56:15 -08:00
|
|
|
|
2020-06-26 19:30:00 +02:00
|
|
|
|
2020-01-21 16:56:15 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-11-03 16:26:10 -08:00
|
|
|
|
2020-01-21 16:56:17 -08:00
|
|
|
|
|
|
|
|
|
2023-08-11 17:57:18 +02:00
|
|
|
|
|
|
|
|
|
2020-01-21 16:56:17 -08:00
|
|
|
|
2023-08-11 17:57:18 +02:00
|
|
|
|
2023-08-11 17:57:25 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-01-21 16:56:17 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-08-11 17:57:18 +02:00
|
|
|
|
2025-11-03 16:26:13 -08:00
|
|
|
|
2023-08-11 17:57:18 +02:00
|
|
|
|
|
|
|
|
|
2025-11-03 16:26:13 -08:00
|
|
|
|
2023-08-11 17:57:18 +02:00
|
|
|
|
2020-01-21 16:56:19 -08:00
|
|
|
|
2023-08-11 17:57:18 +02:00
|
|
|
|
2020-01-21 16:56:17 -08:00
|
|
|
|
|
|
|
|
|
2023-08-11 17:57:18 +02:00
|
|
|
|
2020-01-21 16:56:17 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-01-21 16:56:19 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-01-06 10:57:20 -08:00
|
|
|
|
2023-08-11 17:57:20 +02:00
|
|
|
|
2020-01-21 16:56:19 -08:00
|
|
|
|
|
|
|
|
|
mptcp: pr_debug: add missing \n at the end
pr_debug() have been added in various places in MPTCP code to help
developers to debug some situations. With the dynamic debug feature, it
is easy to enable all or some of them, and asks users to reproduce
issues with extra debug.
Many of these pr_debug() don't end with a new line, while no 'pr_cont()'
are used in MPTCP code. So the goal was not to display multiple debug
messages on one line: they were then not missing the '\n' on purpose.
Not having the new line at the end causes these messages to be printed
with a delay, when something else needs to be printed. This issue is not
visible when many messages need to be printed, but it is annoying and
confusing when only specific messages are expected, e.g.
# echo "func mptcp_pm_add_addr_echoed +fmp" \
> /sys/kernel/debug/dynamic_debug/control
# ./mptcp_join.sh "signal address"; \
echo "$(awk '{print $1}' /proc/uptime) - end"; \
sleep 5s; \
echo "$(awk '{print $1}' /proc/uptime) - restart"; \
./mptcp_join.sh "signal address"
013 signal address
(...)
10.75 - end
15.76 - restart
013 signal address
[ 10.367935] mptcp:mptcp_pm_add_addr_echoed: MPTCP: msk=(...)
(...)
=> a delay of 5 seconds: printed with a 10.36 ts, but after 'restart'
which was printed at the 15.76 ts.
The 'Fixes' tag here below points to the first pr_debug() used without
'\n' in net/mptcp. This patch could be split in many small ones, with
different Fixes tag, but it doesn't seem worth it, because it is easy to
re-generate this patch with this simple 'sed' command:
git grep -l pr_debug -- net/mptcp |
xargs sed -i "s/\(pr_debug(\".*[^n]\)\(\"[,)]\)/\1\\\n\2/g"
So in case of conflicts, simply drop the modifications, and launch this
command.
Fixes: f870fa0b5768 ("mptcp: Add MPTCP socket stubs")
Cc: stable@vger.kernel.org
Reviewed-by: Geliang Tang <geliang@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20240826-net-mptcp-close-extra-sf-fin-v1-4-905199fe1172@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26 19:11:21 +02:00
|
|
|
|
2020-01-21 16:56:19 -08:00
|
|
|
|
2023-01-06 10:57:20 -08:00
|
|
|
|
2023-07-04 22:44:34 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-08-11 17:57:25 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-01-21 16:56:19 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-09-08 16:07:06 +02:00
|
|
|
|
2023-12-22 13:47:23 +01:00
|
|
|
|
2023-01-06 10:57:20 -08:00
|
|
|
|
2020-04-20 16:25:04 +02:00
|
|
|
|
2023-08-11 17:57:20 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-12-22 13:47:23 +01:00
|
|
|
|
2023-08-11 17:57:20 +02:00
|
|
|
|
2023-01-06 10:57:23 -08:00
|
|
|
|
|
|
|
|
|
2023-08-11 17:57:20 +02:00
|
|
|
|
|
|
|
|
|
2023-01-06 10:57:23 -08:00
|
|
|
|
2020-01-21 16:56:19 -08:00
|
|
|
|
|
|
|
|
|
2023-01-06 10:57:20 -08:00
|
|
|
|
2020-01-21 16:56:19 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-11-21 18:02:03 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-11-21 18:02:13 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-11-21 18:02:03 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-11-21 18:02:13 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-11-21 18:02:03 +01:00
|
|
|
|
|
|
|
|
|
2025-11-21 18:02:13 +01:00
|
|
|
|
|
|
|
|
|
2025-11-21 18:02:03 +01:00
|
|
|
|
|
|
|
|
|
2025-11-21 18:02:13 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-11-21 18:02:03 +01:00
|
|
|
|
|
|
|
|
|
2020-01-21 16:56:19 -08:00
|
|
|
|
2024-05-09 09:20:08 -06:00
|
|
|
|
2020-01-21 16:56:19 -08:00
|
|
|
|
|
|
|
|
|
2023-08-11 17:57:22 +02:00
|
|
|
|
2020-01-21 16:56:19 -08:00
|
|
|
|
mptcp: pr_debug: add missing \n at the end
pr_debug() have been added in various places in MPTCP code to help
developers to debug some situations. With the dynamic debug feature, it
is easy to enable all or some of them, and asks users to reproduce
issues with extra debug.
Many of these pr_debug() don't end with a new line, while no 'pr_cont()'
are used in MPTCP code. So the goal was not to display multiple debug
messages on one line: they were then not missing the '\n' on purpose.
Not having the new line at the end causes these messages to be printed
with a delay, when something else needs to be printed. This issue is not
visible when many messages need to be printed, but it is annoying and
confusing when only specific messages are expected, e.g.
# echo "func mptcp_pm_add_addr_echoed +fmp" \
> /sys/kernel/debug/dynamic_debug/control
# ./mptcp_join.sh "signal address"; \
echo "$(awk '{print $1}' /proc/uptime) - end"; \
sleep 5s; \
echo "$(awk '{print $1}' /proc/uptime) - restart"; \
./mptcp_join.sh "signal address"
013 signal address
(...)
10.75 - end
15.76 - restart
013 signal address
[ 10.367935] mptcp:mptcp_pm_add_addr_echoed: MPTCP: msk=(...)
(...)
=> a delay of 5 seconds: printed with a 10.36 ts, but after 'restart'
which was printed at the 15.76 ts.
The 'Fixes' tag here below points to the first pr_debug() used without
'\n' in net/mptcp. This patch could be split in many small ones, with
different Fixes tag, but it doesn't seem worth it, because it is easy to
re-generate this patch with this simple 'sed' command:
git grep -l pr_debug -- net/mptcp |
xargs sed -i "s/\(pr_debug(\".*[^n]\)\(\"[,)]\)/\1\\\n\2/g"
So in case of conflicts, simply drop the modifications, and launch this
command.
Fixes: f870fa0b5768 ("mptcp: Add MPTCP socket stubs")
Cc: stable@vger.kernel.org
Reviewed-by: Geliang Tang <geliang@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20240826-net-mptcp-close-extra-sf-fin-v1-4-905199fe1172@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26 19:11:21 +02:00
|
|
|
|
2020-01-21 16:56:19 -08:00
|
|
|
|
2023-05-31 12:37:04 -07:00
|
|
|
|
2023-04-14 16:08:01 +02:00
|
|
|
|
|
|
|
|
|
2023-08-11 17:57:22 +02:00
|
|
|
|
|
|
|
|
|
2022-01-06 16:20:17 -08:00
|
|
|
|
2020-01-21 16:56:19 -08:00
|
|
|
|
mptcp: pr_debug: add missing \n at the end
pr_debug() have been added in various places in MPTCP code to help
developers to debug some situations. With the dynamic debug feature, it
is easy to enable all or some of them, and asks users to reproduce
issues with extra debug.
Many of these pr_debug() don't end with a new line, while no 'pr_cont()'
are used in MPTCP code. So the goal was not to display multiple debug
messages on one line: they were then not missing the '\n' on purpose.
Not having the new line at the end causes these messages to be printed
with a delay, when something else needs to be printed. This issue is not
visible when many messages need to be printed, but it is annoying and
confusing when only specific messages are expected, e.g.
# echo "func mptcp_pm_add_addr_echoed +fmp" \
> /sys/kernel/debug/dynamic_debug/control
# ./mptcp_join.sh "signal address"; \
echo "$(awk '{print $1}' /proc/uptime) - end"; \
sleep 5s; \
echo "$(awk '{print $1}' /proc/uptime) - restart"; \
./mptcp_join.sh "signal address"
013 signal address
(...)
10.75 - end
15.76 - restart
013 signal address
[ 10.367935] mptcp:mptcp_pm_add_addr_echoed: MPTCP: msk=(...)
(...)
=> a delay of 5 seconds: printed with a 10.36 ts, but after 'restart'
which was printed at the 15.76 ts.
The 'Fixes' tag here below points to the first pr_debug() used without
'\n' in net/mptcp. This patch could be split in many small ones, with
different Fixes tag, but it doesn't seem worth it, because it is easy to
re-generate this patch with this simple 'sed' command:
git grep -l pr_debug -- net/mptcp |
xargs sed -i "s/\(pr_debug(\".*[^n]\)\(\"[,)]\)/\1\\\n\2/g"
So in case of conflicts, simply drop the modifications, and launch this
command.
Fixes: f870fa0b5768 ("mptcp: Add MPTCP socket stubs")
Cc: stable@vger.kernel.org
Reviewed-by: Geliang Tang <geliang@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20240826-net-mptcp-close-extra-sf-fin-v1-4-905199fe1172@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26 19:11:21 +02:00
|
|
|
|
2024-05-09 09:20:08 -06:00
|
|
|
|
2023-05-17 12:16:15 -07:00
|
|
|
|
2024-05-09 09:20:08 -06:00
|
|
|
|
2023-05-17 12:16:15 -07:00
|
|
|
|
mptcp: pr_debug: add missing \n at the end
pr_debug() have been added in various places in MPTCP code to help
developers to debug some situations. With the dynamic debug feature, it
is easy to enable all or some of them, and asks users to reproduce
issues with extra debug.
Many of these pr_debug() don't end with a new line, while no 'pr_cont()'
are used in MPTCP code. So the goal was not to display multiple debug
messages on one line: they were then not missing the '\n' on purpose.
Not having the new line at the end causes these messages to be printed
with a delay, when something else needs to be printed. This issue is not
visible when many messages need to be printed, but it is annoying and
confusing when only specific messages are expected, e.g.
# echo "func mptcp_pm_add_addr_echoed +fmp" \
> /sys/kernel/debug/dynamic_debug/control
# ./mptcp_join.sh "signal address"; \
echo "$(awk '{print $1}' /proc/uptime) - end"; \
sleep 5s; \
echo "$(awk '{print $1}' /proc/uptime) - restart"; \
./mptcp_join.sh "signal address"
013 signal address
(...)
10.75 - end
15.76 - restart
013 signal address
[ 10.367935] mptcp:mptcp_pm_add_addr_echoed: MPTCP: msk=(...)
(...)
=> a delay of 5 seconds: printed with a 10.36 ts, but after 'restart'
which was printed at the 15.76 ts.
The 'Fixes' tag here below points to the first pr_debug() used without
'\n' in net/mptcp. This patch could be split in many small ones, with
different Fixes tag, but it doesn't seem worth it, because it is easy to
re-generate this patch with this simple 'sed' command:
git grep -l pr_debug -- net/mptcp |
xargs sed -i "s/\(pr_debug(\".*[^n]\)\(\"[,)]\)/\1\\\n\2/g"
So in case of conflicts, simply drop the modifications, and launch this
command.
Fixes: f870fa0b5768 ("mptcp: Add MPTCP socket stubs")
Cc: stable@vger.kernel.org
Reviewed-by: Geliang Tang <geliang@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20240826-net-mptcp-close-extra-sf-fin-v1-4-905199fe1172@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26 19:11:21 +02:00
|
|
|
|
2023-12-19 22:31:04 +01:00
|
|
|
|
2020-01-21 16:56:19 -08:00
|
|
|
|
2023-12-19 22:31:04 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-05-09 09:20:08 -06:00
|
|
|
|
2023-12-19 22:31:04 +01:00
|
|
|
|
|
|
|
|
|
2020-11-19 11:45:58 -08:00
|
|
|
|
2022-10-20 19:48:51 +02:00
|
|
|
|
2023-12-19 22:31:04 +01:00
|
|
|
|
2023-03-09 15:49:59 +01:00
|
|
|
|
2022-10-20 19:48:51 +02:00
|
|
|
|
2025-11-21 18:02:03 +01:00
|
|
|
|
2025-09-02 23:11:36 +02:00
|
|
|
|
2026-04-20 18:19:23 +02:00
|
|
|
|
2025-09-02 23:11:36 +02:00
|
|
|
|
2023-04-17 16:00:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-08-11 17:57:26 +02:00
|
|
|
|
|
|
|
|
|
2023-12-22 13:47:23 +01:00
|
|
|
|
2025-11-21 18:02:07 +01:00
|
|
|
|
|
|
|
|
|
2023-04-17 16:00:41 +02:00
|
|
|
|
2023-12-19 22:31:04 +01:00
|
|
|
|
|
|
|
|
|
2024-05-09 09:20:08 -06:00
|
|
|
|
2023-12-19 22:31:04 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-01-21 16:56:19 -08:00
|
|
|
|
2023-05-17 12:16:15 -07:00
|
|
|
|
2020-01-21 16:56:19 -08:00
|
|
|
|
2023-05-17 12:16:15 -07:00
|
|
|
|
2020-01-21 16:56:19 -08:00
|
|
|
|
|
|
|
|
|
2020-11-16 10:48:12 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-03-01 18:43:46 +01:00
|
|
|
|
2020-11-16 10:48:12 +01:00
|
|
|
|
|
|
|
|
|
2024-03-01 18:43:44 +01:00
|
|
|
|
|
|
|
|
|
2024-03-01 18:43:46 +01:00
|
|
|
|
2020-11-27 11:10:27 +01:00
|
|
|
|
2020-11-16 10:48:12 +01:00
|
|
|
|
2020-11-27 11:10:27 +01:00
|
|
|
|
2020-11-16 10:48:12 +01:00
|
|
|
|
|
|
|
|
|
2020-01-21 16:56:17 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-01-21 16:56:25 -08:00
|
|
|
|
mptcp: cope with later TCP fallback
With MPTCP v1, passive connections can fallback to TCP after the
subflow becomes established:
syn + MP_CAPABLE ->
<- syn, ack + MP_CAPABLE
ack, seq = 3 ->
// OoO packet is accepted because in-sequence
// passive socket is created, is in ESTABLISHED
// status and tentatively as MP_CAPABLE
ack, seq = 2 ->
// no MP_CAPABLE opt, subflow should fallback to TCP
We can't use the 'subflow' socket fallback, as we don't have
it available for passive connection.
Instead, when the fallback is detected, replace the mptcp
socket with the underlying TCP subflow. Beyond covering
the above scenario, it makes a TCP fallback socket as efficient
as plain TCP ones.
Co-developed-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Christoph Paasch <cpaasch@apple.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2020-01-21 16:56:33 -08:00
|
|
|
|
2020-01-21 16:56:17 -08:00
|
|
|
|
2023-05-31 12:37:07 -07:00
|
|
|
|
2020-06-29 22:26:25 +02:00
|
|
|
|
2020-01-21 16:56:17 -08:00
|
|
|
|
2020-01-21 16:56:25 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-06-29 22:26:25 +02:00
|
|
|
|
mptcp: pr_debug: add missing \n at the end
pr_debug() have been added in various places in MPTCP code to help
developers to debug some situations. With the dynamic debug feature, it
is easy to enable all or some of them, and asks users to reproduce
issues with extra debug.
Many of these pr_debug() don't end with a new line, while no 'pr_cont()'
are used in MPTCP code. So the goal was not to display multiple debug
messages on one line: they were then not missing the '\n' on purpose.
Not having the new line at the end causes these messages to be printed
with a delay, when something else needs to be printed. This issue is not
visible when many messages need to be printed, but it is annoying and
confusing when only specific messages are expected, e.g.
# echo "func mptcp_pm_add_addr_echoed +fmp" \
> /sys/kernel/debug/dynamic_debug/control
# ./mptcp_join.sh "signal address"; \
echo "$(awk '{print $1}' /proc/uptime) - end"; \
sleep 5s; \
echo "$(awk '{print $1}' /proc/uptime) - restart"; \
./mptcp_join.sh "signal address"
013 signal address
(...)
10.75 - end
15.76 - restart
013 signal address
[ 10.367935] mptcp:mptcp_pm_add_addr_echoed: MPTCP: msk=(...)
(...)
=> a delay of 5 seconds: printed with a 10.36 ts, but after 'restart'
which was printed at the 15.76 ts.
The 'Fixes' tag here below points to the first pr_debug() used without
'\n' in net/mptcp. This patch could be split in many small ones, with
different Fixes tag, but it doesn't seem worth it, because it is easy to
re-generate this patch with this simple 'sed' command:
git grep -l pr_debug -- net/mptcp |
xargs sed -i "s/\(pr_debug(\".*[^n]\)\(\"[,)]\)/\1\\\n\2/g"
So in case of conflicts, simply drop the modifications, and launch this
command.
Fixes: f870fa0b5768 ("mptcp: Add MPTCP socket stubs")
Cc: stable@vger.kernel.org
Reviewed-by: Geliang Tang <geliang@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20240826-net-mptcp-close-extra-sf-fin-v1-4-905199fe1172@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2024-08-26 19:11:21 +02:00
|
|
|
|
2022-01-06 16:20:17 -08:00
|
|
|
|
2023-08-11 17:57:21 +02:00
|
|
|
|
2023-05-31 12:37:04 -07:00
|
|
|
|
2023-08-11 17:57:21 +02:00
|
|
|
|
2022-01-06 16:20:17 -08:00
|
|
|
|
|
|
|
|
|
2023-08-11 17:57:21 +02:00
|
|
|
|
2022-01-06 16:20:17 -08:00
|
|
|
|
2020-06-29 22:26:25 +02:00
|
|
|
|
2023-05-31 12:37:07 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-06-29 22:26:25 +02:00
|
|
|
|
2023-10-23 13:44:38 -07:00
|
|
|
|
2023-05-31 12:37:07 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-08-16 08:15:45 +00:00
|
|
|
|
|
|
|
|
|
2022-09-26 16:27:39 -07:00
|
|
|
|
|
|
|
|
|
2020-06-29 22:26:25 +02:00
|
|
|
|
2020-01-21 16:56:25 -08:00
|
|
|
|
2022-09-30 08:59:34 -07:00
|
|
|
|
2021-02-11 15:30:37 -08:00
|
|
|
|
2023-03-15 20:57:45 +00:00
|
|
|
|
2021-02-11 15:30:37 -08:00
|
|
|
|
|
|
|
|
|
2020-01-21 16:56:17 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-01-30 20:24:25 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-06-02 22:14:16 +10:00
|
|
|
|
|
|
|
|
|
2026-01-30 20:24:25 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-01-30 20:24:27 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-04-03 13:29:29 +02:00
|
|
|
|
2026-01-30 20:24:27 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-01-24 16:04:02 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-04-01 18:57:45 +02:00
|
|
|
|
2020-01-24 16:04:02 -08:00
|
|
|
|
2023-05-31 12:37:03 -07:00
|
|
|
|
2020-01-24 16:04:02 -08:00
|
|
|
|
|
|
|
|
|
2020-06-29 22:26:22 +02:00
|
|
|
|
2020-01-24 16:04:02 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-01-12 18:25:24 +01:00
|
|
|
|
2020-01-24 16:04:02 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-10-23 13:44:38 -07:00
|
|
|
|
2026-01-30 20:24:25 +01:00
|
|
|
|
2026-01-30 20:24:27 +01:00
|
|
|
|
2020-01-24 16:04:02 -08:00
|
|
|
|
2020-01-21 16:56:17 -08:00
|
|
|
|
2020-01-21 16:56:15 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-01-21 16:56:17 -08:00
|
|
|
|
|
|
|
|
|
2020-01-21 16:56:15 -08:00
|
|
|
|
|
|
|
|
|
2021-01-20 15:39:14 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-10-04 13:38:11 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-01-20 15:39:14 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-06-26 19:29:59 +02:00
|
|
|
|
2020-01-21 16:56:15 -08:00
|
|
|
|
2021-01-20 15:39:14 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-01-21 16:56:17 -08:00
|
|
|
|
|
|
|
|
|
2020-03-27 14:48:45 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-01-12 16:34:55 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-01-20 15:39:14 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-01-12 16:34:55 -08:00
|
|
|
|
2022-05-04 09:37:24 -07:00
|
|
|
|
2021-01-20 15:39:14 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-01-21 16:56:17 -08:00
|
|
|
|
2020-03-27 14:48:38 -07:00
|
|
|
|
2023-08-21 15:25:21 -07:00
|
|
|
|
2020-06-26 19:30:00 +02:00
|
|
|
|
2020-01-21 16:56:17 -08:00
|
|
|
|
2020-01-21 16:56:15 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-02-26 10:14:48 +01:00
|
|
|
|
|
|
|
|
|
2026-04-03 13:29:27 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-01-21 16:56:15 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-01-24 16:04:02 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-04-01 18:57:45 +02:00
|
|
|
|
2020-01-24 16:04:02 -08:00
|
|
|
|
2023-05-31 12:37:03 -07:00
|
|
|
|
2020-01-24 16:04:02 -08:00
|
|
|
|
|
|
|
|
|
2020-06-29 22:26:22 +02:00
|
|
|
|
2020-01-24 16:04:02 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-01-12 18:25:24 +01:00
|
|
|
|
2020-01-24 16:04:02 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-05-18 08:28:06 +02:00
|
|
|
|
2020-01-24 16:04:02 -08:00
|
|
|
|
2023-10-23 13:44:38 -07:00
|
|
|
|
2026-01-30 20:24:25 +01:00
|
|
|
|
2026-01-30 20:24:27 +01:00
|
|
|
|
2020-01-24 16:04:02 -08:00
|
|
|
|
|
|
|
|
|
2020-01-21 16:56:15 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-01-21 16:56:17 -08:00
|
|
|
|
2020-01-21 16:56:15 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-06-26 19:29:59 +02:00
|
|
|
|
2020-01-21 16:56:15 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
mptcp: fix slab-use-after-free in __inet_lookup_established
The ehash table lookups are lockless and rely on
SLAB_TYPESAFE_BY_RCU to guarantee socket memory stability
during RCU read-side critical sections. Both tcp_prot and
tcpv6_prot have their slab caches created with this flag
via proto_register().
However, MPTCP's mptcp_subflow_init() copies tcpv6_prot into
tcpv6_prot_override during inet_init() (fs_initcall, level 5),
before inet6_init() (module_init/device_initcall, level 6) has
called proto_register(&tcpv6_prot). At that point,
tcpv6_prot.slab is still NULL, so tcpv6_prot_override.slab
remains NULL permanently.
This causes MPTCP v6 subflow child sockets to be allocated via
kmalloc (falling into kmalloc-4k) instead of the TCPv6 slab
cache. The kmalloc-4k cache lacks SLAB_TYPESAFE_BY_RCU, so
when these sockets are freed without SOCK_RCU_FREE (which is
cleared for child sockets by design), the memory can be
immediately reused. Concurrent ehash lookups under
rcu_read_lock can then access freed memory, triggering a
slab-use-after-free in __inet_lookup_established.
Fix this by splitting the IPv6-specific initialization out of
mptcp_subflow_init() into a new mptcp_subflow_v6_init(), called
from mptcp_proto_v6_init() before protocol registration. This
ensures tcpv6_prot_override.slab correctly inherits the
SLAB_TYPESAFE_BY_RCU slab cache.
Fixes: b19bc2945b40 ("mptcp: implement delegated actions")
Cc: stable@vger.kernel.org
Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20260406031512.189159-1-jiayuan.chen@linux.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-06 11:15:10 +08:00
|
|
|
|
|
|
|
|
|
2020-01-21 16:56:15 -08:00
|
|
|
|
2024-05-13 18:13:29 -07:00
|
|
|
|
2020-01-21 16:56:15 -08:00
|
|
|
|
2020-02-06 00:39:37 +01:00
|
|
|
|
2023-07-20 11:09:01 +00:00
|
|
|
|
2020-01-21 16:56:15 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
