2020-01-21 16:56:15 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-01-21 16:56:26 -08: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
|
|
|
|
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
|
|
|
|
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
|
|
|
|
|
|
|
|
|
2023-12-19 22:31:04 +01:00
|
|
|
|
|
|
|
|
|
2020-04-02 13:44:51 +02:00
|
|
|
|
2023-12-19 22:31:04 +01:00
|
|
|
|
|
|
|
|
|
2020-04-02 13:44:51 +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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-08-31 13:52:10 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-10-26 16:29:15 -07:00
|
|
|
|
|
|
|
|
|
2023-08-31 13:52:10 +00:00
|
|
|
|
2021-10-26 16:29:15 -07: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
|
|
|
|
2022-09-06 20:04:01 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-14 10:01:11 +02:00
|
|
|
|
2021-10-26 16:29:15 -07: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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-10-26 16:29:15 -07:00
|
|
|
|
|
|
|
|
|
2022-06-08 23:34:07 -07:00
|
|
|
|
2023-08-31 13:52:10 +00:00
|
|
|
|
2021-10-26 16:29:15 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-08-31 13:52:10 +00:00
|
|
|
|
2021-10-26 16:29:15 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-06-30 15:17:55 -07:00
|
|
|
|
|
|
|
|
|
2021-10-26 16:29:15 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-11-25 23:29:51 +01:00
|
|
|
|
2021-10-26 16:29:15 -07: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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-10-26 16:29:15 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-06-30 15:17:56 -07:00
|
|
|
|
2021-10-26 16:29:15 -07:00
|
|
|
|
|
|
|
|
|
2022-06-30 15:17:56 -07:00
|
|
|
|
2021-10-26 16:29:15 -07:00
|
|
|
|
2022-06-08 23:34:07 -07:00
|
|
|
|
2022-06-30 15:17:54 -07:00
|
|
|
|
|
|
|
|
|
2021-10-26 16:29:15 -07:00
|
|
|
|
2023-08-31 13:52:10 +00:00
|
|
|
|
2021-10-26 16:29:15 -07:00
|
|
|
|
2020-09-14 10:01:12 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-02-26 10:14:48 +01:00
|
|
|
|
2020-05-25 23:41:13 +02:00
|
|
|
|
2021-06-03 16:24:32 -07:00
|
|
|
|
2020-02-26 10:14:48 +01:00
|
|
|
|
|
|
|
|
|
2020-05-25 23:41:13 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-14 10:01:12 +02:00
|
|
|
|
2020-10-27 15:59:14 +01:00
|
|
|
|
2024-07-31 12:10:14 +02:00
|
|
|
|
|
|
|
|
|
2021-10-26 16:29:15 -07:00
|
|
|
|
2024-07-31 12:10:14 +02:00
|
|
|
|
2020-10-27 15:59:14 +01: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
|
|
|
|
2020-05-25 23:41:13 +02:00
|
|
|
|
2020-09-14 10:01:12 +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
|
|
|
|
2021-10-26 16:29:15 -07:00
|
|
|
|
2020-09-14 10:01:12 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-14 10:01:14 +02:00
|
|
|
|
2020-10-27 15:59:14 +01:00
|
|
|
|
2020-09-14 10:01:12 +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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-16 10:48:09 +01: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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
2022-02-24 16:52:59 -08:00
|
|
|
|
2021-04-23 09:40:33 -07:00
|
|
|
|
2022-02-24 16:52:59 -08: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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-08-13 15:15:41 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-08-13 15:15:42 -07: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
|
|
|
|
2021-06-22 12:25:23 -07: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
|
|
|
|
2020-11-24 22:51:24 +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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
2021-06-22 12:25:23 -07:00
|
|
|
|
2021-07-09 17:20:51 -07: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
|
|
|
|
|
|
|
|
|
2020-11-16 10:48:14 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-07-28 15:12:03 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-16 10:48:14 +01: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
|
|
|
|
|
|
|
|
|
2023-12-22 13:47:23 +01:00
|
|
|
|
2020-07-28 15:12:03 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-16 10:48:14 +01: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
|
|
|
|
2020-11-16 10:48:14 +01:00
|
|
|
|
2020-07-28 15:12:03 -07: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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-03 11:05:03 -08: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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-10-06 08:27:34 +02:00
|
|
|
|
2022-09-30 08:59:34 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-10-06 08:27:34 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-02-26 10:14:48 +01:00
|
|
|
|
2020-10-06 08:27:34 +02: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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-14 10:01:12 +02: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
|
|
|
|
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-11-03 11:05:03 -08:00
|
|
|
|
2020-02-26 10:14:49 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-02-26 10:14:48 +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
|
|
|
|
|
|
|
|
|
2020-09-14 10:01:09 +02: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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-27 11:10:24 +01:00
|
|
|
|
|
|
|
|
|
2021-06-10 15:59:44 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-01-06 16:20:26 -08:00
|
|
|
|
2021-06-10 15:59:44 -07:00
|
|
|
|
2020-09-14 10:01:12 +02:00
|
|
|
|
2020-11-27 11:10:24 +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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-02-26 10:14:46 +01:00
|
|
|
|
2020-09-14 10:01:09 +02:00
|
|
|
|
2020-02-26 10:14:46 +01:00
|
|
|
|
2020-11-03 11:05:03 -08:00
|
|
|
|
2020-02-26 10:14:46 +01:00
|
|
|
|
2020-12-09 12:03:31 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-03 11:05:03 -08: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
|
|
|
|
2024-07-31 12:10:14 +02: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
|
|
|
|
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
|
|
|
|
|
|
|
|
|
2023-10-23 13:44:38 -07:00
|
|
|
|
2020-09-14 10:01:09 +02: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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
2022-01-06 16:20:25 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-04-15 16:44:53 -07:00
|
|
|
|
2023-06-20 18:30:17 +02:00
|
|
|
|
2022-01-06 16:20:25 -08:00
|
|
|
|
2023-05-31 12:37:08 -07: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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-09-16 12:52:48 +02:00
|
|
|
|
2020-03-27 14:48:44 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-16 10:48:09 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-08-13 15:15:41 -07:00
|
|
|
|
2020-03-27 14:48:44 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-16 10:48:05 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-01-21 16:56:26 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-01-06 10:57:17 -08:00
|
|
|
|
2020-01-21 16:56:26 -08: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-01-21 16:56:26 -08: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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-05-27 16:31:37 -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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-10-23 13:44:42 -07: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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
2022-05-04 14:54:04 -07: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
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-04-22 14:55:41 -07:00
|
|
|
|
2022-04-22 14:55:39 -07:00
|
|
|
|
|
|
|
|
|
2022-06-27 18:02:38 -07: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
|
|
|
|
|
|
|
|
|
2023-10-18 11:23:54 -07: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
|
|
|
|
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
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-05-04 14:54:04 -07:00
|
|
|
|
2021-12-17 15:37:00 -08:00
|
|
|
|
2021-01-20 15:39:11 +01:00
|
|
|
|
2022-05-04 14:54:04 -07: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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-09-06 22:55:41 +02: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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-16 10:48:10 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-10-26 16:29:16 -07:00
|
|
|
|
2020-11-16 10:48:10 +01:00
|
|
|
|
2021-08-13 15:15:41 -07:00
|
|
|
|
2023-09-16 12:52:48 +02:00
|
|
|
|
|
|
|
|
|
2022-09-06 22:55:41 +02:00
|
|
|
|
2023-06-20 18:24:21 +02: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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
2022-11-25 23:29:47 +01: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
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
2020-12-16 12:48:35 +01:00
|
|
|
|
2021-03-04 13:32:14 -08: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
|
|
|
|
|
|
|
|
|
2020-02-26 10:14:48 +01:00
|
|
|
|
|
|
|
|
|
2021-06-03 16:24:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-02-26 10:14:48 +01:00
|
|
|
|
2021-04-23 11:17:08 -07:00
|
|
|
|
2020-02-26 10:14:48 +01:00
|
|
|
|
|
|
|
|
|
2021-04-23 11:17:08 -07:00
|
|
|
|
2020-02-26 10:14:48 +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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-12-03 14:35:32 -08:00
|
|
|
|
2021-04-23 11:17:08 -07:00
|
|
|
|
2021-12-03 14:35:32 -08:00
|
|
|
|
2023-10-23 13:44:38 -07:00
|
|
|
|
2021-12-03 14:35:32 -08:00
|
|
|
|
2020-02-26 10:14:48 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-04-23 11:17:08 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-07-09 17:20:51 -07:00
|
|
|
|
2021-04-23 11:17:08 -07:00
|
|
|
|
|
|
|
|
|
2023-10-23 13:44:38 -07:00
|
|
|
|
2021-04-23 11:17:08 -07:00
|
|
|
|
2020-02-26 10:14:48 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-06-30 21:24:45 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-07-20 20:47:50 +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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-07-20 20:47:50 +02:00
|
|
|
|
2020-06-30 21:24:45 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-07-20 20:47:50 +02:00
|
|
|
|
2020-06-30 21:24:45 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-07-20 09:50:18 -07:00
|
|
|
|
2020-06-30 21:24:45 +02:00
|
|
|
|
|
|
|
|
|
2023-07-20 20:47:50 +02:00
|
|
|
|
2020-06-30 21:24:45 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-06-05 09:15:41 +02:00
|
|
|
|
2022-07-22 11:22:00 -07:00
|
|
|
|
2020-06-30 21:24:45 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-06-05 09:15:40 +02:00
|
|
|
|
2020-06-30 21:24:45 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-14 10:01:18 +02:00
|
|
|
|
2020-06-30 21:24:45 +02:00
|
|
|
|
|
|
|
|
|
2020-09-14 10:01:18 +02:00
|
|
|
|
2020-06-30 21:24:45 +02:00
|
|
|
|
2024-04-04 11:42:31 +00:00
|
|
|
|
2024-11-08 11:58:17 +01:00
|
|
|
|
|
|
|
|
|
2020-09-14 10:01:18 +02:00
|
|
|
|
2020-06-30 21:24:45 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-27 11:10:24 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-10-26 16:29:15 -07:00
|
|
|
|
2021-07-09 17:20:51 -07:00
|
|
|
|
2020-11-27 11:10:24 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-02-11 15:30:41 -08:00
|
|
|
|
2020-02-26 10:14:48 +01:00
|
|
|
|
2020-11-27 11:10:24 +01:00
|
|
|
|
2020-02-26 10:14:48 +01:00
|
|
|
|
2020-11-27 11:10:24 +01:00
|
|
|
|
2020-09-14 10:01:17 +02:00
|
|
|
|
2020-02-26 10:14:48 +01:00
|
|
|
|
|
|
|
|
|
2020-11-03 11:05:04 -08:00
|
|
|
|
2020-02-26 10:14:48 +01:00
|
|
|
|
2020-11-27 11:10:24 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-02-26 10:14:48 +01:00
|
|
|
|
|
|
|
|
|
2020-11-03 11:05:04 -08:00
|
|
|
|
2020-11-27 11:10:24 +01:00
|
|
|
|
2021-02-11 15:30:41 -08:00
|
|
|
|
2020-02-26 10:14:48 +01:00
|
|
|
|
2020-11-27 11:10:24 +01:00
|
|
|
|
2021-06-10 15:59:44 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-03 11:05:04 -08: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
|
|
|
|
2020-11-27 11:10:24 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-02-26 10:14:48 +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
|
|
|
|
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: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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-10-26 16:29:15 -07:00
|
|
|
|
2020-11-24 22:51:24 +01: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
|
|
|
|
2024-11-08 11:58:16 +01:00
|
|
|
|
2020-01-21 16:56:26 -08:00
|
|
|
|
2021-06-03 16:24:32 -07: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
|
|
|
|
2020-11-19 11:46:03 -08: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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-27 11:10:24 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-02-11 15:30:41 -08:00
|
|
|
|
2020-11-27 11:10:24 +01:00
|
|
|
|
2020-01-21 16:56:26 -08:00
|
|
|
|
2020-11-27 11:10:24 +01: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-11-08 11:58:16 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-01-21 16:56:26 -08:00
|
|
|
|
2021-06-21 15:54:35 -07:00
|
|
|
|
2024-11-08 11:58:16 +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
|
|
|
|
|
|
|
|
|
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-10-07 15:05:00 -07: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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
2020-12-16 12:48:33 +01:00
|
|
|
|
2020-11-16 10:48:09 +01:00
|
|
|
|
2023-08-03 18:27:29 +02:00
|
|
|
|
2023-10-18 11:23:55 -07:00
|
|
|
|
2022-09-30 08:59:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-01-06 16:20:16 -08:00
|
|
|
|
2022-09-30 08:59:32 -07:00
|
|
|
|
2022-01-06 16:20:16 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-10-18 11:23:55 -07: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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
2021-03-04 13:32:13 -08:00
|
|
|
|
2020-02-26 10:14:47 +01:00
|
|
|
|
2021-03-04 13:32:13 -08:00
|
|
|
|
2023-08-21 15:25:20 -07:00
|
|
|
|
2020-11-16 10:48:06 +01:00
|
|
|
|
2020-03-27 14:48:48 -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
|
|
|
|
2021-05-27 16:31:37 -07:00
|
|
|
|
2021-09-24 14:12:38 -07:00
|
|
|
|
|
|
|
|
|
2023-08-21 15:25:20 -07:00
|
|
|
|
2021-03-04 13:32:13 -08:00
|
|
|
|
2021-04-23 09:40:33 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-09-24 14:12:38 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-04-23 09:40:33 -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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-06-17 16:46:17 -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
|
|
|
|
|
|
|
|
|
2021-09-24 14:12:38 -07:00
|
|
|
|
|
|
|
|
|
2023-09-16 12:52:48 +02: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
|
|
|
|
|
|
|
|
|
2023-09-16 12:52:49 +02:00
|
|
|
|
2023-10-23 13:44:34 -07: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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
2022-09-30 08:59:32 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-12-22 13:47:23 +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
|
|
|
|
|
|
|
|
|
2022-01-06 16:20:22 -08: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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
2020-01-21 16:56:18 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-03-27 14:48:40 -07:00
|
|
|
|
2020-03-27 14:48:43 -07:00
|
|
|
|
2020-02-26 10:14:47 +01:00
|
|
|
|
2020-11-27 11:10:24 +01:00
|
|
|
|
2020-09-14 10:01:12 +02:00
|
|
|
|
2020-11-16 10:48:07 +01:00
|
|
|
|
2024-02-02 12:40:09 +01:00
|
|
|
|
2021-07-09 17:20:51 -07:00
|
|
|
|
2021-08-13 15:15:41 -07:00
|
|
|
|
2023-10-23 13:44:38 -07: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
|
|
|
|
2022-04-22 14:55:38 -07: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
|
|
|
|
|
|
|
|
|
2020-03-27 14:48:44 -07:00
|
|
|
|
|
|
|
|
|
2023-09-16 12:52:48 +02: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
|
|
|
|
|
|
|
|
|
2020-03-27 14:48:45 -07: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
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
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
|
|
|
|
2024-02-02 12:40:09 +01:00
|
|
|
|
2020-11-27 11:10:24 +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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-10-23 13:44:38 -07: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
|
|
|
|
2022-11-10 15:23:18 -08:00
|
|
|
|
2022-06-27 18:02:37 -07: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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-03-27 14:48:43 -07: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
|
|
|
|
2023-09-16 12:52:48 +02:00
|
|
|
|
2023-09-16 12:52:49 +02:00
|
|
|
|
2022-01-06 16:20:16 -08:00
|
|
|
|
2022-11-10 15:23:18 -08:00
|
|
|
|
|
|
|
|
|
2022-01-06 16:20:16 -08:00
|
|
|
|
2022-08-04 17:21:25 -07: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
|
|
|
|
2022-01-06 16:20:16 -08: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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-02-23 17:14:18 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-02-06 00:39:37 +01: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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-10-23 13:44:42 -07:00
|
|
|
|
2023-05-31 12:37:05 -07: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-06-30 21:24:45 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-02-08 19:03:50 +01:00
|
|
|
|
2020-06-30 21:24:45 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-08-04 17:21:25 -07:00
|
|
|
|
2020-09-24 08:29:57 +08:00
|
|
|
|
2022-08-04 17:21:25 -07:00
|
|
|
|
2020-11-27 11:10:24 +01:00
|
|
|
|
|
|
|
|
|
2020-11-27 11:10:27 +01:00
|
|
|
|
|
|
|
|
|
2022-08-04 17:21:25 -07:00
|
|
|
|
2022-09-06 22:55:39 +02:00
|
|
|
|
2022-08-04 17:21:25 -07:00
|
|
|
|
|
|
|
|
|
2020-11-27 11:10:24 +01:00
|
|
|
|
2022-01-06 16:20:16 -08:00
|
|
|
|
2020-11-27 11:10:24 +01:00
|
|
|
|
2021-10-26 16:29:15 -07:00
|
|
|
|
2020-09-24 08:29:57 +08:00
|
|
|
|
2022-01-06 16:20:16 -08:00
|
|
|
|
2021-10-26 16:29:15 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-08-31 13:52:09 +00:00
|
|
|
|
2023-08-31 13:52:10 +00:00
|
|
|
|
2020-09-24 08:29:57 +08:00
|
|
|
|
|
|
|
|
|
2022-05-03 19:38:49 -07:00
|
|
|
|
2020-09-24 08:29:57 +08: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
|
|
|
|
|
|
|
|
|
2022-08-04 17:21:25 -07: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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
2021-03-26 11:26:30 -07:00
|
|
|
|
2022-01-06 16:20:26 -08:00
|
|
|
|
2024-02-08 19:03:49 +01:00
|
|
|
|
2023-06-20 18:24:20 +02: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
|
|
|
|
|
|
|
|
|
2021-03-04 13:32:14 -08:00
|
|
|
|
|
|
|
|
|
2020-11-27 11:10:27 +01: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-11-27 11:10:27 +01:00
|
|
|
|
2020-11-27 11:10:24 +01:00
|
|
|
|
2020-02-26 10:14:52 +01: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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
2020-03-27 14:48:39 -07:00
|
|
|
|
2021-04-01 16:19:44 -07:00
|
|
|
|
2020-03-27 14:48:39 -07:00
|
|
|
|
2023-05-31 12:37:08 -07: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
|
|
|
|
2022-01-06 16:20:25 -08: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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-16 10:48:09 +01:00
|
|
|
|
2022-01-06 16:20:25 -08:00
|
|
|
|
2022-01-06 16:20:26 -08: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
|
|
|
|
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-10-26 16:29:15 -07:00
|
|
|
|
|
|
|
|
|
2023-08-31 13:52:10 +00:00
|
|
|
|
|
|
|
|
|
2021-10-26 16:29:15 -07: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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
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
|
|
|
|
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
|
|
|
|
2022-10-21 15:58:55 -07:00
|
|
|
|
|
|
|
|
|
2024-09-09 22:09: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
|
|
|
|
2021-10-26 16:29:15 -07: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
|
|
|
|
2020-03-27 14:48:45 -07: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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
2020-01-21 16:56:19 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-08-03 21:00:44 +08:00
|
|
|
|
2020-01-21 16:56:19 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-04-17 16:00:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-08-11 17:57:26 +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
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-01-20 15:39:14 +01: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
|
|
|
|
|
|
|
|
|
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
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
