August 2024 - Linux-stable-mirror

[PATCH v1 05/41] mptcp: pm: do not ignore 'subflow' if 'signal' flag is also set

by Santosh Sakore

From: "Matthieu Baerts (NGI0)" <matttbe(a)kernel.org> Up to the 'Fixes' commit, having an endpoint with both the 'signal' and 'subflow' flags, resulted in the creation of a subflow and an address announcement using the address linked to this endpoint. After this commit, only the address announcement was done, ignoring the 'subflow' flag. That's because the same bitmap is used for the two flags. It is OK to keep this single bitmap, the already selected local endpoint simply have to be re-used, but not via select_local_address() not to look at the just modified bitmap. Note that it is unusual to set the two flags together: creating a new subflow using a new local address will implicitly advertise it to the other peer. So in theory, no need to advertise it explicitly as well. Maybe there are use-cases -- the subflow might not reach the other peer that way, we can ask the other peer to try initiating the new subflow without delay -- or very likely the user is confused, and put both flags "just to be sure at least the right one is set". Still, if it is allowed, the kernel should do what has been asked: using this endpoint to announce the address and to create a new subflow from it. An alternative is to forbid the use of the two flags together, but that's probably too late, there are maybe use-cases, and it was working before. This patch will avoid people complaining subflows are not created using the endpoint they added with the 'subflow' and 'signal' flag. Note that with the current patch, the subflow might not be created in some corner cases, e.g. if the 'subflows' limit was reached when sending the ADD_ADDR, but changed later on. It is probably not worth splitting id_avail_bitmap per target ('signal', 'subflow'), which will add another large field to the msk "just" to track (again) endpoints. Anyway, currently when the limits are changed, the kernel doesn't check if new subflows can be created or removed, because we would need to keep track of the received ADD_ADDR, and more. It sounds OK to assume that the limits should be properly configured before establishing new connections. Fixes: 86e39e04482b ("mptcp: keep track of local endpoint still available for each msk") Cc: stable(a)vger.kernel.org Suggested-by: Paolo Abeni <pabeni(a)redhat.com> Reviewed-by: Mat Martineau <martineau(a)kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org> Link: https://patch.msgid.link/20240731-upstream-net-20240731-mptcp-endp-subflow-… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> --- net/mptcp/pm_netlink.c | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/net/mptcp/pm_netlink.c b/net/mptcp/pm_netlink.c index 2be7af377cda..4cae2aa7be5c 100644 --- a/net/mptcp/pm_netlink.c +++ b/net/mptcp/pm_netlink.c @@ -512,8 +512,8 @@ __lookup_addr(struct pm_nl_pernet *pernet, const struct mptcp_addr_info *info) static void mptcp_pm_create_subflow_or_signal_addr(struct mptcp_sock *msk) { + struct mptcp_pm_addr_entry *local, *signal_and_subflow = NULL; struct sock *sk = (struct sock *)msk; - struct mptcp_pm_addr_entry *local; unsigned int add_addr_signal_max; unsigned int local_addr_max; struct pm_nl_pernet *pernet; @@ -579,6 +579,9 @@ static void mptcp_pm_create_subflow_or_signal_addr(struct mptcp_sock *msk) msk->pm.add_addr_signaled++; mptcp_pm_announce_addr(msk, &local->addr, false); mptcp_pm_nl_addr_send_ack(msk); + + if (local->flags & MPTCP_PM_ADDR_FLAG_SUBFLOW) + signal_and_subflow = local; } subflow: @@ -589,9 +592,14 @@ static void mptcp_pm_create_subflow_or_signal_addr(struct mptcp_sock *msk) bool fullmesh; int i, nr; - local = select_local_address(pernet, msk); - if (!local) - break; + if (signal_and_subflow) { + local = signal_and_subflow; + signal_and_subflow = NULL; + } else { + local = select_local_address(pernet, msk); + if (!local) + break; + } fullmesh = !!(local->flags & MPTCP_PM_ADDR_FLAG_FULLMESH); -- 2.17.1

1 year, 2 months

1
0
0 0

[PATCH v1 04/41] mptcp: pm: don't try to create sf if alloc failed

by Santosh Sakore

From: "Matthieu Baerts (NGI0)" <matttbe(a)kernel.org> It sounds better to avoid wasting cycles and / or put extreme memory pressure on the system by trying to create new subflows if it was not possible to add a new item in the announce list. While at it, a warning is now printed if the entry was already in the list as it should not happen with the in-kernel path-manager. With this PM, mptcp_pm_alloc_anno_list() should only fail in case of memory pressure. Fixes: b6c08380860b ("mptcp: remove addr and subflow in PM netlink") Cc: stable(a)vger.kernel.org Suggested-by: Paolo Abeni <pabeni(a)redhat.com> Reviewed-by: Mat Martineau <martineau(a)kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org> Link: https://patch.msgid.link/20240731-upstream-net-20240731-mptcp-endp-subflow-… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> --- net/mptcp/pm_netlink.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/net/mptcp/pm_netlink.c b/net/mptcp/pm_netlink.c index 780f4cca165c..2be7af377cda 100644 --- a/net/mptcp/pm_netlink.c +++ b/net/mptcp/pm_netlink.c @@ -348,7 +348,7 @@ bool mptcp_pm_alloc_anno_list(struct mptcp_sock *msk, add_entry = mptcp_lookup_anno_list_by_saddr(msk, addr); if (add_entry) { - if (mptcp_pm_is_kernel(msk)) + if (WARN_ON_ONCE(mptcp_pm_is_kernel(msk))) return false; sk_reset_timer(sk, &add_entry->add_timer, @@ -555,8 +555,6 @@ static void mptcp_pm_create_subflow_or_signal_addr(struct mptcp_sock *msk) /* check first for announce */ if (msk->pm.add_addr_signaled < add_addr_signal_max) { - local = select_signal_address(pernet, msk); - /* due to racing events on both ends we can reach here while * previous add address is still running: if we invoke now * mptcp_pm_announce_addr(), that will fail and the @@ -567,11 +565,15 @@ static void mptcp_pm_create_subflow_or_signal_addr(struct mptcp_sock *msk) if (msk->pm.addr_signal & BIT(MPTCP_ADD_ADDR_SIGNAL)) return; + local = select_signal_address(pernet, msk); if (!local) goto subflow; + /* If the alloc fails, we are on memory pressure, not worth + * continuing, and trying to create subflows. + */ if (!mptcp_pm_alloc_anno_list(msk, &local->addr)) - goto subflow; + return; __clear_bit(local->addr.id, msk->pm.id_avail_bitmap); msk->pm.add_addr_signaled++; -- 2.17.1

1 year, 2 months

1
0
0 0

[PATCH v1 02/41] mptcp: pm: deny endp with signal + subflow + port

by Santosh Sakore

From: "Matthieu Baerts (NGI0)" <matttbe(a)kernel.org> As mentioned in the 'Fixes' commit, the port flag is only supported by the 'signal' flag, and not by the 'subflow' one. Then if both the 'signal' and 'subflow' flags are set, the problem is the same: the feature cannot work with the 'subflow' flag. Technically, if both the 'signal' and 'subflow' flags are set, it will be possible to create the listening socket, but not to establish a subflow using this source port. So better to explicitly deny it, not to create some confusions because the expected behaviour is not possible. Fixes: 09f12c3ab7a5 ("mptcp: allow to use port and non-signal in set_flags") Cc: stable(a)vger.kernel.org Reviewed-by: Mat Martineau <martineau(a)kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org> Link: https://patch.msgid.link/20240731-upstream-net-20240731-mptcp-endp-subflow-… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> --- net/mptcp/pm_netlink.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/mptcp/pm_netlink.c b/net/mptcp/pm_netlink.c index 37954a0b087d..c921d07e5940 100644 --- a/net/mptcp/pm_netlink.c +++ b/net/mptcp/pm_netlink.c @@ -1328,8 +1328,8 @@ int mptcp_pm_nl_add_addr_doit(struct sk_buff *skb, struct genl_info *info) if (ret < 0) return ret; - if (addr.addr.port && !(addr.flags & MPTCP_PM_ADDR_FLAG_SIGNAL)) { - GENL_SET_ERR_MSG(info, "flags must have signal when using port"); + if (addr.addr.port && !address_use_port(&addr)) { + GENL_SET_ERR_MSG(info, "flags must have signal and not subflow when using port"); return -EINVAL; } -- 2.17.1

1 year, 2 months

1
0
0 0

[PATCH 5.10.y 00/13] arm64: errata: Speculative SSBS workaround

by Mark Rutland

Hi, This series is a v5.10-only backport (based on v5.10.223) of the upstream workaround for SSBS errata on Arm Ltd CPUs, as affected parts are likely to be used with stable kernels. This does not apply to earlier stable trees, which will receive a separate backport. The errata mean that an MSR to the SSBS special-purpose register does not affect subsequent speculative instructions, permitting speculative store bypassing for a window of time. The upstream support was original posted as: * https://lore.kernel.org/linux-arm-kernel/20240508081400.235362-1-mark.rutla… "arm64: errata: Add workaround for Arm errata 3194386 and 3312417" Present in v6.10 * https://lore.kernel.org/linux-arm-kernel/20240603111812.1514101-1-mark.rutl… "arm64: errata: Expand speculative SSBS workaround" Present in v6.11-rc1 * https://lore.kernel.org/linux-arm-kernel/20240801101803.1982459-1-mark.rutl… "arm64: errata: Expand speculative SSBS workaround (again)" Present in v6.11-rc2 This backport applies the patches which are not present in v5.10.y, and as prerequisites backports HWCAP detection based on user-visible id register values and the addition of Neoverse-V2 MIDR values. The spec_bar() macro exists in v5.10.y as its removal was not backported, and hence it doesn't need to be restored. I have tested the backport (when applied to v5.10.223), ensuring that the detection logic works and that the HWCAP and string in /proc/cpuinfo are both hidden when the relevant errata are detected. Mark. Besar Wicaksono (1): arm64: Add Neoverse-V2 part James Morse (1): arm64: cpufeature: Force HWCAP to be based on the sysreg visible to user-space Mark Rutland (11): arm64: cputype: Add Cortex-X4 definitions arm64: cputype: Add Neoverse-V3 definitions arm64: errata: Add workaround for Arm errata 3194386 and 3312417 arm64: cputype: Add Cortex-X3 definitions arm64: cputype: Add Cortex-A720 definitions arm64: cputype: Add Cortex-X925 definitions arm64: errata: Unify speculative SSBS errata logic arm64: errata: Expand speculative SSBS workaround arm64: cputype: Add Cortex-X1C definitions arm64: cputype: Add Cortex-A725 definitions arm64: errata: Expand speculative SSBS workaround (again) Documentation/arm64/silicon-errata.rst | 36 +++++++++++++++++++ arch/arm64/Kconfig | 38 ++++++++++++++++++++ arch/arm64/include/asm/cpucaps.h | 3 +- arch/arm64/include/asm/cputype.h | 16 +++++++++ arch/arm64/kernel/cpu_errata.c | 31 +++++++++++++++++ arch/arm64/kernel/cpufeature.c | 48 ++++++++++++++++++++++---- arch/arm64/kernel/proton-pack.c | 12 +++++++ 7 files changed, 176 insertions(+), 8 deletions(-) -- 2.30.2

1 year, 2 months

1
13
0 0

[PATCH 5.15.y 00/14] arm64: errata: Speculative SSBS workaround

by Mark Rutland

Hi, This series is a v5.15-only backport (based on v5.15.164) of the upstream workaround for SSBS errata on Arm Ltd CPUs, as affected parts are likely to be used with stable kernels. This does not apply to earlier stable trees, which will receive a separate backport. The errata mean that an MSR to the SSBS special-purpose register does not affect subsequent speculative instructions, permitting speculative store bypassing for a window of time. The upstream support was original posted as: * https://lore.kernel.org/linux-arm-kernel/20240508081400.235362-1-mark.rutla… "arm64: errata: Add workaround for Arm errata 3194386 and 3312417" Present in v6.10 * https://lore.kernel.org/linux-arm-kernel/20240603111812.1514101-1-mark.rutl… "arm64: errata: Expand speculative SSBS workaround" Present in v6.11-rc1 * https://lore.kernel.org/linux-arm-kernel/20240801101803.1982459-1-mark.rutl… "arm64: errata: Expand speculative SSBS workaround (again)" Present in v6.11-rc2 This backport applies the patches which are not present in v5.15.y, and as prerequisites backports HWCAP detection based on user-visible id register values, the addition of Neoverse-V2 MIDR values, and the restoration of the spec_bar() macro. I have tested the backport (when applied to v5.15.164), ensuring that the detection logic works and that the HWCAP and string in /proc/cpuinfo are both hidden when the relevant errata are detected. Mark. Besar Wicaksono (1): arm64: Add Neoverse-V2 part James Morse (1): arm64: cpufeature: Force HWCAP to be based on the sysreg visible to user-space Mark Rutland (12): arm64: barrier: Restore spec_bar() macro arm64: cputype: Add Cortex-X4 definitions arm64: cputype: Add Neoverse-V3 definitions arm64: errata: Add workaround for Arm errata 3194386 and 3312417 arm64: cputype: Add Cortex-X3 definitions arm64: cputype: Add Cortex-A720 definitions arm64: cputype: Add Cortex-X925 definitions arm64: errata: Unify speculative SSBS errata logic arm64: errata: Expand speculative SSBS workaround arm64: cputype: Add Cortex-X1C definitions arm64: cputype: Add Cortex-A725 definitions arm64: errata: Expand speculative SSBS workaround (again) Documentation/arm64/silicon-errata.rst | 36 +++++++++++++++++++ arch/arm64/Kconfig | 38 ++++++++++++++++++++ arch/arm64/include/asm/barrier.h | 4 +++ arch/arm64/include/asm/cputype.h | 16 +++++++++ arch/arm64/kernel/cpu_errata.c | 31 +++++++++++++++++ arch/arm64/kernel/cpufeature.c | 48 ++++++++++++++++++++++---- arch/arm64/kernel/proton-pack.c | 12 +++++++ arch/arm64/tools/cpucaps | 1 + 8 files changed, 179 insertions(+), 7 deletions(-) -- 2.30.2

1 year, 2 months

1
14
0 0

FAILED: patch "[PATCH] selftests: mptcp: join: check backup support in signal endp" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.10.y git checkout FETCH_HEAD git cherry-pick -x f833470c27832136d4416d8fc55d658082af0989 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024080721-alarm-boots-fe07@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: f833470c2783 ("selftests: mptcp: join: check backup support in signal endp") 935ff5bb8a1c ("selftests: mptcp: join: validate backup in MPJ") c8f021eec581 ("selftests: mptcp: join: fix subflow_send_ack lookup") e571fb09c893 ("selftests: mptcp: add speed env var") 4aadde088a58 ("selftests: mptcp: add fullmesh env var") 080b7f5733fd ("selftests: mptcp: add fastclose env var") 662aa22d7dcd ("selftests: mptcp: set all env vars as local ones") 9e9d176df8e9 ("selftests: mptcp: add pm_nl_set_endpoint helper") 1534f87ee0dc ("selftests: mptcp: drop sflags parameter") 595ef566a2ef ("selftests: mptcp: drop addr_nr_ns1/2 parameters") 0c93af1f8907 ("selftests: mptcp: drop test_linkfail parameter") be7e9786c915 ("selftests: mptcp: set FAILING_LINKS in run_tests") 4369c198e599 ("selftests: mptcp: test userspace pm out of transfer") 173780ff18a9 ("Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From f833470c27832136d4416d8fc55d658082af0989 Mon Sep 17 00:00:00 2001 From: "Matthieu Baerts (NGI0)" <matttbe(a)kernel.org> Date: Sat, 27 Jul 2024 12:01:29 +0200 Subject: [PATCH] selftests: mptcp: join: check backup support in signal endp Before the previous commit, 'signal' endpoints with the 'backup' flag were ignored when sending the MP_JOIN. The MPTCP Join selftest has then been modified to validate this case: the "single address, backup" test, is now validating the MP_JOIN with a backup flag as it is what we expect it to do with such name. The previous version has been kept, but renamed to "single address, switch to backup" to avoid confusions. The "single address with port, backup" test is also now validating the MPJ with a backup flag, which makes more sense than checking the switch to backup with an MP_PRIO. The "mpc backup both sides" test is now validating that the backup flag is also set in MP_JOIN from and to the addresses used in the initial subflow, using the special ID 0. The 'Fixes' tag here below is the same as the one from the previous commit: this patch here is not fixing anything wrong in the selftests, but it validates the previous fix for an issue introduced by this commit ID. Fixes: 4596a2c1b7f5 ("mptcp: allow creating non-backup subflows") Cc: stable(a)vger.kernel.org Reviewed-by: Mat Martineau <martineau(a)kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org> Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> diff --git a/tools/testing/selftests/net/mptcp/mptcp_join.sh b/tools/testing/selftests/net/mptcp/mptcp_join.sh index e6c8d86017f3..4df48f1f14ab 100755 --- a/tools/testing/selftests/net/mptcp/mptcp_join.sh +++ b/tools/testing/selftests/net/mptcp/mptcp_join.sh @@ -2639,6 +2639,19 @@ backup_tests() # single address, backup if reset "single address, backup" && + continue_if mptcp_lib_kallsyms_has "subflow_rebuild_header$"; then + pm_nl_set_limits $ns1 0 1 + pm_nl_add_endpoint $ns1 10.0.2.1 flags signal,backup + pm_nl_set_limits $ns2 1 1 + sflags=nobackup speed=slow \ + run_tests $ns1 $ns2 10.0.1.1 + chk_join_nr 1 1 1 + chk_add_nr 1 1 + chk_prio_nr 1 0 0 1 + fi + + # single address, switch to backup + if reset "single address, switch to backup" && continue_if mptcp_lib_kallsyms_has "subflow_rebuild_header$"; then pm_nl_set_limits $ns1 0 1 pm_nl_add_endpoint $ns1 10.0.2.1 flags signal @@ -2654,13 +2667,13 @@ backup_tests() if reset "single address with port, backup" && continue_if mptcp_lib_kallsyms_has "subflow_rebuild_header$"; then pm_nl_set_limits $ns1 0 1 - pm_nl_add_endpoint $ns1 10.0.2.1 flags signal port 10100 + pm_nl_add_endpoint $ns1 10.0.2.1 flags signal,backup port 10100 pm_nl_set_limits $ns2 1 1 - sflags=backup speed=slow \ + sflags=nobackup speed=slow \ run_tests $ns1 $ns2 10.0.1.1 chk_join_nr 1 1 1 chk_add_nr 1 1 - chk_prio_nr 1 1 0 0 + chk_prio_nr 1 0 0 1 fi if reset "mpc backup" && @@ -2674,12 +2687,21 @@ backup_tests() if reset "mpc backup both sides" && continue_if mptcp_lib_kallsyms_doesnt_have "T mptcp_subflow_send_ack$"; then - pm_nl_add_endpoint $ns1 10.0.1.1 flags subflow,backup + pm_nl_set_limits $ns1 0 2 + pm_nl_set_limits $ns2 1 2 + pm_nl_add_endpoint $ns1 10.0.1.1 flags signal,backup pm_nl_add_endpoint $ns2 10.0.1.2 flags subflow,backup + + # 10.0.2.2 (non-backup) -> 10.0.1.1 (backup) + pm_nl_add_endpoint $ns2 10.0.2.2 flags subflow + # 10.0.1.2 (backup) -> 10.0.2.1 (non-backup) + pm_nl_add_endpoint $ns1 10.0.2.1 flags signal + ip -net "$ns2" route add 10.0.2.1 via 10.0.1.1 dev ns2eth1 # force this path + speed=slow \ run_tests $ns1 $ns2 10.0.1.1 - chk_join_nr 0 0 0 - chk_prio_nr 1 1 0 0 + chk_join_nr 2 2 2 + chk_prio_nr 1 1 1 1 fi if reset "mpc switch to backup" &&

1 year, 2 months

2
1
0 0

FAILED: patch "[PATCH] selftests: mptcp: join: validate backup in MPJ" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.10.y git checkout FETCH_HEAD git cherry-pick -x 935ff5bb8a1cfcdf8e60c8f5c794d0bbbc234437 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024080708-abreast-sphere-f97c@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: 935ff5bb8a1c ("selftests: mptcp: join: validate backup in MPJ") 985de45923e2 ("selftests: mptcp: centralize stats dumping") 0639fa230a21 ("selftests: mptcp: add explicit check for new mibs") 9095ce97bf8a ("selftests: mptcp: add mptcp_info tests") 070d6dafacba ("selftests: mptcp: stop tests earlier") a635a8c3df66 ("selftests: mptcp: allow more slack for slow test-case") a3735625572d ("selftests: mptcp: make evts global in mptcp_join") 6bf41020b72b ("selftests: mptcp: update and extend fastclose test-cases") a1c3bdd9c5df ("selftests: mptcp: move prefix tests of addr_nr_ns2 together") 914f6a59b10f ("selftests: mptcp: add MPC backup tests") 5e986ec46874 ("selftests: mptcp: userspace pm subflow tests") 97040cf9806e ("selftests: mptcp: userspace pm address tests") d7e6f5836038 ("Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 935ff5bb8a1cfcdf8e60c8f5c794d0bbbc234437 Mon Sep 17 00:00:00 2001 From: "Matthieu Baerts (NGI0)" <matttbe(a)kernel.org> Date: Sat, 27 Jul 2024 12:01:27 +0200 Subject: [PATCH] selftests: mptcp: join: validate backup in MPJ A peer can notify the other one that a subflow has to be treated as "backup" by two different ways: either by sending a dedicated MP_PRIO notification, or by setting the backup flag in the MP_JOIN handshake. The selftests were previously monitoring the former, but not the latter. This is what is now done here by looking at these new MIB counters when validating the 'backup' cases: MPTcpExtMPJoinSynBackupRx MPTcpExtMPJoinSynAckBackupRx The 'Fixes' tag here below is the same as the one from the previous commit: this patch here is not fixing anything wrong in the selftests, but it will help to validate a new fix for an issue introduced by this commit ID. Fixes: 4596a2c1b7f5 ("mptcp: allow creating non-backup subflows") Cc: stable(a)vger.kernel.org Reviewed-by: Mat Martineau <martineau(a)kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org> Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> diff --git a/tools/testing/selftests/net/mptcp/mptcp_join.sh b/tools/testing/selftests/net/mptcp/mptcp_join.sh index 55d84a1bde15..e6c8d86017f3 100755 --- a/tools/testing/selftests/net/mptcp/mptcp_join.sh +++ b/tools/testing/selftests/net/mptcp/mptcp_join.sh @@ -1634,6 +1634,8 @@ chk_prio_nr() { local mp_prio_nr_tx=$1 local mp_prio_nr_rx=$2 + local mpj_syn=$3 + local mpj_syn_ack=$4 local count print_check "ptx" @@ -1655,6 +1657,26 @@ chk_prio_nr() else print_ok fi + + print_check "syn backup" + count=$(mptcp_lib_get_counter ${ns1} "MPTcpExtMPJoinSynBackupRx") + if [ -z "$count" ]; then + print_skip + elif [ "$count" != "$mpj_syn" ]; then + fail_test "got $count JOIN[s] syn with Backup expected $mpj_syn" + else + print_ok + fi + + print_check "synack backup" + count=$(mptcp_lib_get_counter ${ns2} "MPTcpExtMPJoinSynAckBackupRx") + if [ -z "$count" ]; then + print_skip + elif [ "$count" != "$mpj_syn_ack" ]; then + fail_test "got $count JOIN[s] synack with Backup expected $mpj_syn_ack" + else + print_ok + fi } chk_subflow_nr() @@ -2612,7 +2634,7 @@ backup_tests() sflags=nobackup speed=slow \ run_tests $ns1 $ns2 10.0.1.1 chk_join_nr 1 1 1 - chk_prio_nr 0 1 + chk_prio_nr 0 1 1 0 fi # single address, backup @@ -2625,7 +2647,7 @@ backup_tests() run_tests $ns1 $ns2 10.0.1.1 chk_join_nr 1 1 1 chk_add_nr 1 1 - chk_prio_nr 1 1 + chk_prio_nr 1 1 0 0 fi # single address with port, backup @@ -2638,7 +2660,7 @@ backup_tests() run_tests $ns1 $ns2 10.0.1.1 chk_join_nr 1 1 1 chk_add_nr 1 1 - chk_prio_nr 1 1 + chk_prio_nr 1 1 0 0 fi if reset "mpc backup" && @@ -2647,7 +2669,7 @@ backup_tests() speed=slow \ run_tests $ns1 $ns2 10.0.1.1 chk_join_nr 0 0 0 - chk_prio_nr 0 1 + chk_prio_nr 0 1 0 0 fi if reset "mpc backup both sides" && @@ -2657,7 +2679,7 @@ backup_tests() speed=slow \ run_tests $ns1 $ns2 10.0.1.1 chk_join_nr 0 0 0 - chk_prio_nr 1 1 + chk_prio_nr 1 1 0 0 fi if reset "mpc switch to backup" && @@ -2666,7 +2688,7 @@ backup_tests() sflags=backup speed=slow \ run_tests $ns1 $ns2 10.0.1.1 chk_join_nr 0 0 0 - chk_prio_nr 0 1 + chk_prio_nr 0 1 0 0 fi if reset "mpc switch to backup both sides" && @@ -2676,7 +2698,7 @@ backup_tests() sflags=backup speed=slow \ run_tests $ns1 $ns2 10.0.1.1 chk_join_nr 0 0 0 - chk_prio_nr 1 1 + chk_prio_nr 1 1 0 0 fi } @@ -3053,7 +3075,7 @@ fullmesh_tests() addr_nr_ns2=1 sflags=backup,fullmesh speed=slow \ run_tests $ns1 $ns2 10.0.1.1 chk_join_nr 2 2 2 - chk_prio_nr 0 1 + chk_prio_nr 0 1 1 0 chk_rm_nr 0 1 fi @@ -3066,7 +3088,7 @@ fullmesh_tests() sflags=nobackup,nofullmesh speed=slow \ run_tests $ns1 $ns2 10.0.1.1 chk_join_nr 2 2 2 - chk_prio_nr 0 1 + chk_prio_nr 0 1 1 0 chk_rm_nr 0 1 fi } @@ -3318,7 +3340,7 @@ userspace_tests() sflags=backup speed=slow \ run_tests $ns1 $ns2 10.0.1.1 chk_join_nr 1 1 0 - chk_prio_nr 0 0 + chk_prio_nr 0 0 0 0 fi # userspace pm type prevents rm_addr

1 year, 2 months

2
1
0 0

[PATCH 6.1.y 00/13] arm64: errata: Speculative SSBS workaround

by Mark Rutland

Hi, This series is a v6.1-only backport (based on v6.1.103) of the upstream workaround for SSBS errata on Arm Ltd CPUs, as affected parts are likely to be used with stable kernels. This does not apply to earlier stable trees, which will receive a separate backport. The errata mean that an MSR to the SSBS special-purpose register does not affect subsequent speculative instructions, permitting speculative store bypassing for a window of time. The upstream support was original posted as: * https://lore.kernel.org/linux-arm-kernel/20240508081400.235362-1-mark.rutla… "arm64: errata: Add workaround for Arm errata 3194386 and 3312417" Present in v6.10 * https://lore.kernel.org/linux-arm-kernel/20240603111812.1514101-1-mark.rutl… "arm64: errata: Expand speculative SSBS workaround" Present in v6.11-rc1 * https://lore.kernel.org/linux-arm-kernel/20240801101803.1982459-1-mark.rutl… "arm64: errata: Expand speculative SSBS workaround (again)" Present in v6.11-rc2 This backport applies the patches which are not present in v6.1.y and as prerequisites backports the addition of the Neoverse-V2 MIDR values and the restoration of the spec_bar() macro. I have tested the backport (when applied to v6.1.103), ensuring that the detection logic works and that the HWCAP and string in /proc/cpuinfo are both hidden when the relevant errata are detected. Mark. Besar Wicaksono (1): arm64: Add Neoverse-V2 part Mark Rutland (12): arm64: barrier: Restore spec_bar() macro arm64: cputype: Add Cortex-X4 definitions arm64: cputype: Add Neoverse-V3 definitions arm64: errata: Add workaround for Arm errata 3194386 and 3312417 arm64: cputype: Add Cortex-X3 definitions arm64: cputype: Add Cortex-A720 definitions arm64: cputype: Add Cortex-X925 definitions arm64: errata: Unify speculative SSBS errata logic arm64: errata: Expand speculative SSBS workaround arm64: cputype: Add Cortex-X1C definitions arm64: cputype: Add Cortex-A725 definitions arm64: errata: Expand speculative SSBS workaround (again) Documentation/arm64/silicon-errata.rst | 36 ++++++++++++++++++++++++ arch/arm64/Kconfig | 38 ++++++++++++++++++++++++++ arch/arm64/include/asm/barrier.h | 4 +++ arch/arm64/include/asm/cputype.h | 16 +++++++++++ arch/arm64/kernel/cpu_errata.c | 31 +++++++++++++++++++++ arch/arm64/kernel/cpufeature.c | 12 ++++++++ arch/arm64/kernel/proton-pack.c | 12 ++++++++ arch/arm64/tools/cpucaps | 1 + 8 files changed, 150 insertions(+) -- 2.30.2

1 year, 2 months

1
13
0 0

[PATCH v1] mm/vmalloc: fix page mapping if vm_area_alloc_pages() with high order fallback to order 0

by Hailong Liu

The __vmap_pages_range_noflush() assumes its argument pages** contains pages with the same page shift. However, since commit e9c3cda4d86e (mm, vmalloc: fix high order __GFP_NOFAIL allocations), if gfp_flags includes __GFP_NOFAIL with high order in vm_area_alloc_pages() and page allocation failed for high order, the pages** may contain two different page shifts (high order and order-0). This could lead __vmap_pages_range_noflush() to perform incorrect mappings, potentially resulting in memory corruption. Users might encounter this as follows (vmap_allow_huge = true, 2M is for PMD_SIZE): kvmalloc(2M, __GFP_NOFAIL|GFP_X) __vmalloc_node_range_noprof(vm_flags=VM_ALLOW_HUGE_VMAP) vm_area_alloc_pages(order=9) ---> order-9 allocation failed and fallback to order-0 vmap_pages_range() vmap_pages_range_noflush() __vmap_pages_range_noflush(page_shift = 21) ----> wrong mapping happens We can remove the fallback code because if a high-order allocation fails, __vmalloc_node_range_noprof() will retry with order-0. Therefore, it is unnecessary to fallback to order-0 here. Therefore, fix this by removing the fallback code. Fixes: e9c3cda4d86e ("mm, vmalloc: fix high order __GFP_NOFAIL allocations") Signed-off-by: Hailong Liu <hailong.liu(a)oppo.com> Reported-by: Tangquan.Zheng <zhengtangquan(a)oppo.com> Cc: <stable(a)vger.kernel.org> CC: Barry Song <21cnbao(a)gmail.com> CC: Baoquan He <bhe(a)redhat.com> CC: Matthew Wilcox <willy(a)infradead.org> --- mm/vmalloc.c | 11 ++--------- mm/vmalloc.c.rej | 10 ++++++++++ 2 files changed, 12 insertions(+), 9 deletions(-) create mode 100644 mm/vmalloc.c.rej diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 6b783baf12a1..af2de36549d6 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -3584,15 +3584,8 @@ vm_area_alloc_pages(gfp_t gfp, int nid, page = alloc_pages_noprof(alloc_gfp, order); else page = alloc_pages_node_noprof(nid, alloc_gfp, order); - if (unlikely(!page)) { - if (!nofail) - break; - - /* fall back to the zero order allocations */ - alloc_gfp |= __GFP_NOFAIL; - order = 0; - continue; - } + if (unlikely(!page)) + break; /* * Higher order allocations must be able to be treated as diff --git a/mm/vmalloc.c.rej b/mm/vmalloc.c.rej new file mode 100644 index 000000000000..c28017088319 --- /dev/null +++ b/mm/vmalloc.c.rej @@ -0,0 +1,10 @@ +--- mm/vmalloc.c ++++ mm/vmalloc.c +@@ -3000,6 +3005,7 @@ vm_area_alloc_pages(gfp_t gfp, int nid, + unsigned int nr_allocated = 0; + gfp_t alloc_gfp = gfp; + bool nofail = false; ++ bool fallback = false; + struct page *page; + int i; + --- Baoquan suggests set page_shift to 0 if fallback in (2 and concern about performance of retry with order-0. But IMO with retry, - Save memory usage if high order allocation failed. - Keep consistancy with align and page-shift. - make use of bulk allocator with order-0 [2] https://lore.kernel.org/lkml/20240725035318.471-1-hailong.liu@oppo.com/ -- 2.34.1

1 year, 2 months

2
2
0 0

FAILED: patch "[PATCH] selftests: mptcp: join: check backup support in signal endp" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.15.y git checkout FETCH_HEAD git cherry-pick -x f833470c27832136d4416d8fc55d658082af0989 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024080720-baritone-outspoken-6a54@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: f833470c2783 ("selftests: mptcp: join: check backup support in signal endp") 935ff5bb8a1c ("selftests: mptcp: join: validate backup in MPJ") c8f021eec581 ("selftests: mptcp: join: fix subflow_send_ack lookup") e571fb09c893 ("selftests: mptcp: add speed env var") 4aadde088a58 ("selftests: mptcp: add fullmesh env var") 080b7f5733fd ("selftests: mptcp: add fastclose env var") 662aa22d7dcd ("selftests: mptcp: set all env vars as local ones") 9e9d176df8e9 ("selftests: mptcp: add pm_nl_set_endpoint helper") 1534f87ee0dc ("selftests: mptcp: drop sflags parameter") 595ef566a2ef ("selftests: mptcp: drop addr_nr_ns1/2 parameters") 0c93af1f8907 ("selftests: mptcp: drop test_linkfail parameter") be7e9786c915 ("selftests: mptcp: set FAILING_LINKS in run_tests") 4369c198e599 ("selftests: mptcp: test userspace pm out of transfer") 173780ff18a9 ("Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From f833470c27832136d4416d8fc55d658082af0989 Mon Sep 17 00:00:00 2001 From: "Matthieu Baerts (NGI0)" <matttbe(a)kernel.org> Date: Sat, 27 Jul 2024 12:01:29 +0200 Subject: [PATCH] selftests: mptcp: join: check backup support in signal endp Before the previous commit, 'signal' endpoints with the 'backup' flag were ignored when sending the MP_JOIN. The MPTCP Join selftest has then been modified to validate this case: the "single address, backup" test, is now validating the MP_JOIN with a backup flag as it is what we expect it to do with such name. The previous version has been kept, but renamed to "single address, switch to backup" to avoid confusions. The "single address with port, backup" test is also now validating the MPJ with a backup flag, which makes more sense than checking the switch to backup with an MP_PRIO. The "mpc backup both sides" test is now validating that the backup flag is also set in MP_JOIN from and to the addresses used in the initial subflow, using the special ID 0. The 'Fixes' tag here below is the same as the one from the previous commit: this patch here is not fixing anything wrong in the selftests, but it validates the previous fix for an issue introduced by this commit ID. Fixes: 4596a2c1b7f5 ("mptcp: allow creating non-backup subflows") Cc: stable(a)vger.kernel.org Reviewed-by: Mat Martineau <martineau(a)kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org> Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> diff --git a/tools/testing/selftests/net/mptcp/mptcp_join.sh b/tools/testing/selftests/net/mptcp/mptcp_join.sh index e6c8d86017f3..4df48f1f14ab 100755 --- a/tools/testing/selftests/net/mptcp/mptcp_join.sh +++ b/tools/testing/selftests/net/mptcp/mptcp_join.sh @@ -2639,6 +2639,19 @@ backup_tests() # single address, backup if reset "single address, backup" && + continue_if mptcp_lib_kallsyms_has "subflow_rebuild_header$"; then + pm_nl_set_limits $ns1 0 1 + pm_nl_add_endpoint $ns1 10.0.2.1 flags signal,backup + pm_nl_set_limits $ns2 1 1 + sflags=nobackup speed=slow \ + run_tests $ns1 $ns2 10.0.1.1 + chk_join_nr 1 1 1 + chk_add_nr 1 1 + chk_prio_nr 1 0 0 1 + fi + + # single address, switch to backup + if reset "single address, switch to backup" && continue_if mptcp_lib_kallsyms_has "subflow_rebuild_header$"; then pm_nl_set_limits $ns1 0 1 pm_nl_add_endpoint $ns1 10.0.2.1 flags signal @@ -2654,13 +2667,13 @@ backup_tests() if reset "single address with port, backup" && continue_if mptcp_lib_kallsyms_has "subflow_rebuild_header$"; then pm_nl_set_limits $ns1 0 1 - pm_nl_add_endpoint $ns1 10.0.2.1 flags signal port 10100 + pm_nl_add_endpoint $ns1 10.0.2.1 flags signal,backup port 10100 pm_nl_set_limits $ns2 1 1 - sflags=backup speed=slow \ + sflags=nobackup speed=slow \ run_tests $ns1 $ns2 10.0.1.1 chk_join_nr 1 1 1 chk_add_nr 1 1 - chk_prio_nr 1 1 0 0 + chk_prio_nr 1 0 0 1 fi if reset "mpc backup" && @@ -2674,12 +2687,21 @@ backup_tests() if reset "mpc backup both sides" && continue_if mptcp_lib_kallsyms_doesnt_have "T mptcp_subflow_send_ack$"; then - pm_nl_add_endpoint $ns1 10.0.1.1 flags subflow,backup + pm_nl_set_limits $ns1 0 2 + pm_nl_set_limits $ns2 1 2 + pm_nl_add_endpoint $ns1 10.0.1.1 flags signal,backup pm_nl_add_endpoint $ns2 10.0.1.2 flags subflow,backup + + # 10.0.2.2 (non-backup) -> 10.0.1.1 (backup) + pm_nl_add_endpoint $ns2 10.0.2.2 flags subflow + # 10.0.1.2 (backup) -> 10.0.2.1 (non-backup) + pm_nl_add_endpoint $ns1 10.0.2.1 flags signal + ip -net "$ns2" route add 10.0.2.1 via 10.0.1.1 dev ns2eth1 # force this path + speed=slow \ run_tests $ns1 $ns2 10.0.1.1 - chk_join_nr 0 0 0 - chk_prio_nr 1 1 0 0 + chk_join_nr 2 2 2 + chk_prio_nr 1 1 1 1 fi if reset "mpc switch to backup" &&

1 year, 2 months

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror August 2024