From: Greg Kroah-Hartman Date: Mon, 17 Jun 2024 18:23:08 +0000 (+0200) Subject: 6.6-stable patches X-Git-Tag: v6.1.95~94 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=b3c8486e4a13f8f84b02271a8516906cef4610a6;p=thirdparty%2Fkernel%2Fstable-queue.git 6.6-stable patches added patches: acpi-x86-force-storaged3enable-on-more-products.patch drm-exynos-hdmi-report-safe-640x480-mode-as-a-fallback-when-no-edid-found.patch drm-exynos-vidi-fix-memory-leak-in-.get_modes.patch mptcp-ensure-snd_una-is-properly-initialized-on-connect.patch mptcp-pm-inc-rmaddr-mib-counter-once-per-rm_addr-id.patch mptcp-pm-update-add_addr-counters-after-connect.patch x86-mm-numa-use-numa_no_node-when-calling-memblock_set_node.patch --- diff --git a/queue-6.6/acpi-x86-force-storaged3enable-on-more-products.patch b/queue-6.6/acpi-x86-force-storaged3enable-on-more-products.patch new file mode 100644 index 00000000000..4e8bbde8d13 --- /dev/null +++ b/queue-6.6/acpi-x86-force-storaged3enable-on-more-products.patch @@ -0,0 +1,80 @@ +From e79a10652bbd320649da705ca1ea0c04351af403 Mon Sep 17 00:00:00 2001 +From: Mario Limonciello +Date: Thu, 9 May 2024 13:45:02 -0500 +Subject: ACPI: x86: Force StorageD3Enable on more products + +From: Mario Limonciello + +commit e79a10652bbd320649da705ca1ea0c04351af403 upstream. + +A Rembrandt-based HP thin client is reported to have problems where +the NVME disk isn't present after resume from s2idle. + +This is because the NVME disk wasn't put into D3 at suspend, and +that happened because the StorageD3Enable _DSD was missing in the BIOS. + +As AMD's architecture requires that the NVME is in D3 for s2idle, adjust +the criteria for force_storage_d3 to match *all* Zen SoCs when the FADT +advertises low power idle support. + +This will ensure that any future products with this BIOS deficiency don't +need to be added to the allow list of overrides. + +Cc: All applicable +Signed-off-by: Mario Limonciello +Acked-by: Hans de Goede +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman +--- + drivers/acpi/x86/utils.c | 24 ++++++++++-------------- + 1 file changed, 10 insertions(+), 14 deletions(-) + +--- a/drivers/acpi/x86/utils.c ++++ b/drivers/acpi/x86/utils.c +@@ -198,16 +198,16 @@ bool acpi_device_override_status(struct + } + + /* +- * AMD systems from Renoir and Lucienne *require* that the NVME controller ++ * AMD systems from Renoir onwards *require* that the NVME controller + * is put into D3 over a Modern Standby / suspend-to-idle cycle. + * + * This is "typically" accomplished using the `StorageD3Enable` + * property in the _DSD that is checked via the `acpi_storage_d3` function +- * but this property was introduced after many of these systems launched +- * and most OEM systems don't have it in their BIOS. ++ * but some OEM systems still don't have it in their BIOS. + * + * The Microsoft documentation for StorageD3Enable mentioned that Windows has +- * a hardcoded allowlist for D3 support, which was used for these platforms. ++ * a hardcoded allowlist for D3 support as well as a registry key to override ++ * the BIOS, which has been used for these cases. + * + * This allows quirking on Linux in a similar fashion. + * +@@ -220,19 +220,15 @@ bool acpi_device_override_status(struct + * https://bugzilla.kernel.org/show_bug.cgi?id=216773 + * https://bugzilla.kernel.org/show_bug.cgi?id=217003 + * 2) On at least one HP system StorageD3Enable is missing on the second NVME +- disk in the system. ++ * disk in the system. ++ * 3) On at least one HP Rembrandt system StorageD3Enable is missing on the only ++ * NVME device. + */ +-static const struct x86_cpu_id storage_d3_cpu_ids[] = { +- X86_MATCH_VENDOR_FAM_MODEL(AMD, 23, 24, NULL), /* Picasso */ +- X86_MATCH_VENDOR_FAM_MODEL(AMD, 23, 96, NULL), /* Renoir */ +- X86_MATCH_VENDOR_FAM_MODEL(AMD, 23, 104, NULL), /* Lucienne */ +- X86_MATCH_VENDOR_FAM_MODEL(AMD, 25, 80, NULL), /* Cezanne */ +- {} +-}; +- + bool force_storage_d3(void) + { +- return x86_match_cpu(storage_d3_cpu_ids); ++ if (!cpu_feature_enabled(X86_FEATURE_ZEN)) ++ return false; ++ return acpi_gbl_FADT.flags & ACPI_FADT_LOW_POWER_S0; + } + + /* diff --git a/queue-6.6/drm-exynos-hdmi-report-safe-640x480-mode-as-a-fallback-when-no-edid-found.patch b/queue-6.6/drm-exynos-hdmi-report-safe-640x480-mode-as-a-fallback-when-no-edid-found.patch new file mode 100644 index 00000000000..88acadb5293 --- /dev/null +++ b/queue-6.6/drm-exynos-hdmi-report-safe-640x480-mode-as-a-fallback-when-no-edid-found.patch @@ -0,0 +1,128 @@ +From 799d4b392417ed6889030a5b2335ccb6dcf030ab Mon Sep 17 00:00:00 2001 +From: Marek Szyprowski +Date: Thu, 25 Apr 2024 11:48:51 +0200 +Subject: drm/exynos: hdmi: report safe 640x480 mode as a fallback when no EDID found + +From: Marek Szyprowski + +commit 799d4b392417ed6889030a5b2335ccb6dcf030ab upstream. + +When reading EDID fails and driver reports no modes available, the DRM +core adds an artificial 1024x786 mode to the connector. Unfortunately +some variants of the Exynos HDMI (like the one in Exynos4 SoCs) are not +able to drive such mode, so report a safe 640x480 mode instead of nothing +in case of the EDID reading failure. + +This fixes the following issue observed on Trats2 board since commit +13d5b040363c ("drm/exynos: do not return negative values from .get_modes()"): + +[drm] Exynos DRM: using 11c00000.fimd device for DMA mapping operations +exynos-drm exynos-drm: bound 11c00000.fimd (ops fimd_component_ops) +exynos-drm exynos-drm: bound 12c10000.mixer (ops mixer_component_ops) +exynos-dsi 11c80000.dsi: [drm:samsung_dsim_host_attach] Attached s6e8aa0 device (lanes:4 bpp:24 mode-flags:0x10b) +exynos-drm exynos-drm: bound 11c80000.dsi (ops exynos_dsi_component_ops) +exynos-drm exynos-drm: bound 12d00000.hdmi (ops hdmi_component_ops) +[drm] Initialized exynos 1.1.0 20180330 for exynos-drm on minor 1 +exynos-hdmi 12d00000.hdmi: [drm:hdmiphy_enable.part.0] *ERROR* PLL could not reach steady state +panel-samsung-s6e8aa0 11c80000.dsi.0: ID: 0xa2, 0x20, 0x8c +exynos-mixer 12c10000.mixer: timeout waiting for VSYNC +------------[ cut here ]------------ +WARNING: CPU: 1 PID: 11 at drivers/gpu/drm/drm_atomic_helper.c:1682 drm_atomic_helper_wait_for_vblanks.part.0+0x2b0/0x2b8 +[CRTC:70:crtc-1] vblank wait timed out +Modules linked in: +CPU: 1 PID: 11 Comm: kworker/u16:0 Not tainted 6.9.0-rc5-next-20240424 #14913 +Hardware name: Samsung Exynos (Flattened Device Tree) +Workqueue: events_unbound deferred_probe_work_func +Call trace: + unwind_backtrace from show_stack+0x10/0x14 + show_stack from dump_stack_lvl+0x68/0x88 + dump_stack_lvl from __warn+0x7c/0x1c4 + __warn from warn_slowpath_fmt+0x11c/0x1a8 + warn_slowpath_fmt from drm_atomic_helper_wait_for_vblanks.part.0+0x2b0/0x2b8 + drm_atomic_helper_wait_for_vblanks.part.0 from drm_atomic_helper_commit_tail_rpm+0x7c/0x8c + drm_atomic_helper_commit_tail_rpm from commit_tail+0x9c/0x184 + commit_tail from drm_atomic_helper_commit+0x168/0x190 + drm_atomic_helper_commit from drm_atomic_commit+0xb4/0xe0 + drm_atomic_commit from drm_client_modeset_commit_atomic+0x23c/0x27c + drm_client_modeset_commit_atomic from drm_client_modeset_commit_locked+0x60/0x1cc + drm_client_modeset_commit_locked from drm_client_modeset_commit+0x24/0x40 + drm_client_modeset_commit from __drm_fb_helper_restore_fbdev_mode_unlocked+0x9c/0xc4 + __drm_fb_helper_restore_fbdev_mode_unlocked from drm_fb_helper_set_par+0x2c/0x3c + drm_fb_helper_set_par from fbcon_init+0x3d8/0x550 + fbcon_init from visual_init+0xc0/0x108 + visual_init from do_bind_con_driver+0x1b8/0x3a4 + do_bind_con_driver from do_take_over_console+0x140/0x1ec + do_take_over_console from do_fbcon_takeover+0x70/0xd0 + do_fbcon_takeover from fbcon_fb_registered+0x19c/0x1ac + fbcon_fb_registered from register_framebuffer+0x190/0x21c + register_framebuffer from __drm_fb_helper_initial_config_and_unlock+0x350/0x574 + __drm_fb_helper_initial_config_and_unlock from exynos_drm_fbdev_client_hotplug+0x6c/0xb0 + exynos_drm_fbdev_client_hotplug from drm_client_register+0x58/0x94 + drm_client_register from exynos_drm_bind+0x160/0x190 + exynos_drm_bind from try_to_bring_up_aggregate_device+0x200/0x2d8 + try_to_bring_up_aggregate_device from __component_add+0xb0/0x170 + __component_add from mixer_probe+0x74/0xcc + mixer_probe from platform_probe+0x5c/0xb8 + platform_probe from really_probe+0xe0/0x3d8 + really_probe from __driver_probe_device+0x9c/0x1e4 + __driver_probe_device from driver_probe_device+0x30/0xc0 + driver_probe_device from __device_attach_driver+0xa8/0x120 + __device_attach_driver from bus_for_each_drv+0x80/0xcc + bus_for_each_drv from __device_attach+0xac/0x1fc + __device_attach from bus_probe_device+0x8c/0x90 + bus_probe_device from deferred_probe_work_func+0x98/0xe0 + deferred_probe_work_func from process_one_work+0x240/0x6d0 + process_one_work from worker_thread+0x1a0/0x3f4 + worker_thread from kthread+0x104/0x138 + kthread from ret_from_fork+0x14/0x28 +Exception stack(0xf0895fb0 to 0xf0895ff8) +... +irq event stamp: 82357 +hardirqs last enabled at (82363): [] vprintk_emit+0x308/0x33c +hardirqs last disabled at (82368): [] vprintk_emit+0x2bc/0x33c +softirqs last enabled at (81614): [] __do_softirq+0x320/0x500 +softirqs last disabled at (81609): [] __irq_exit_rcu+0x130/0x184 +---[ end trace 0000000000000000 ]--- +exynos-drm exynos-drm: [drm] *ERROR* flip_done timed out +exynos-drm exynos-drm: [drm] *ERROR* [CRTC:70:crtc-1] commit wait timed out +exynos-drm exynos-drm: [drm] *ERROR* flip_done timed out +exynos-drm exynos-drm: [drm] *ERROR* [CONNECTOR:74:HDMI-A-1] commit wait timed out +exynos-drm exynos-drm: [drm] *ERROR* flip_done timed out +exynos-drm exynos-drm: [drm] *ERROR* [PLANE:56:plane-5] commit wait timed out +exynos-mixer 12c10000.mixer: timeout waiting for VSYNC + +Cc: stable@vger.kernel.org +Fixes: 13d5b040363c ("drm/exynos: do not return negative values from .get_modes()") +Signed-off-by: Marek Szyprowski +Signed-off-by: Inki Dae +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/exynos/exynos_hdmi.c | 7 +++++-- + 1 file changed, 5 insertions(+), 2 deletions(-) + +--- a/drivers/gpu/drm/exynos/exynos_hdmi.c ++++ b/drivers/gpu/drm/exynos/exynos_hdmi.c +@@ -887,11 +887,11 @@ static int hdmi_get_modes(struct drm_con + int ret; + + if (!hdata->ddc_adpt) +- return 0; ++ goto no_edid; + + edid = drm_get_edid(connector, hdata->ddc_adpt); + if (!edid) +- return 0; ++ goto no_edid; + + hdata->dvi_mode = !connector->display_info.is_hdmi; + DRM_DEV_DEBUG_KMS(hdata->dev, "%s : width[%d] x height[%d]\n", +@@ -906,6 +906,9 @@ static int hdmi_get_modes(struct drm_con + kfree(edid); + + return ret; ++ ++no_edid: ++ return drm_add_modes_noedid(connector, 640, 480); + } + + static int hdmi_find_phy_conf(struct hdmi_context *hdata, u32 pixel_clock) diff --git a/queue-6.6/drm-exynos-vidi-fix-memory-leak-in-.get_modes.patch b/queue-6.6/drm-exynos-vidi-fix-memory-leak-in-.get_modes.patch new file mode 100644 index 00000000000..b60884c6bf6 --- /dev/null +++ b/queue-6.6/drm-exynos-vidi-fix-memory-leak-in-.get_modes.patch @@ -0,0 +1,42 @@ +From 38e3825631b1f314b21e3ade00b5a4d737eb054e Mon Sep 17 00:00:00 2001 +From: Jani Nikula +Date: Thu, 30 May 2024 13:01:51 +0300 +Subject: drm/exynos/vidi: fix memory leak in .get_modes() + +From: Jani Nikula + +commit 38e3825631b1f314b21e3ade00b5a4d737eb054e upstream. + +The duplicated EDID is never freed. Fix it. + +Cc: stable@vger.kernel.org +Signed-off-by: Jani Nikula +Signed-off-by: Inki Dae +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/exynos/exynos_drm_vidi.c | 7 ++++++- + 1 file changed, 6 insertions(+), 1 deletion(-) + +--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c ++++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c +@@ -309,6 +309,7 @@ static int vidi_get_modes(struct drm_con + struct vidi_context *ctx = ctx_from_connector(connector); + struct edid *edid; + int edid_len; ++ int count; + + /* + * the edid data comes from user side and it would be set +@@ -328,7 +329,11 @@ static int vidi_get_modes(struct drm_con + + drm_connector_update_edid_property(connector, edid); + +- return drm_add_edid_modes(connector, edid); ++ count = drm_add_edid_modes(connector, edid); ++ ++ kfree(edid); ++ ++ return count; + } + + static const struct drm_connector_helper_funcs vidi_connector_helper_funcs = { diff --git a/queue-6.6/mptcp-ensure-snd_una-is-properly-initialized-on-connect.patch b/queue-6.6/mptcp-ensure-snd_una-is-properly-initialized-on-connect.patch new file mode 100644 index 00000000000..bc92891005b --- /dev/null +++ b/queue-6.6/mptcp-ensure-snd_una-is-properly-initialized-on-connect.patch @@ -0,0 +1,42 @@ +From 8031b58c3a9b1db3ef68b3bd749fbee2e1e1aaa3 Mon Sep 17 00:00:00 2001 +From: Paolo Abeni +Date: Fri, 7 Jun 2024 17:01:48 +0200 +Subject: mptcp: ensure snd_una is properly initialized on connect + +From: Paolo Abeni + +commit 8031b58c3a9b1db3ef68b3bd749fbee2e1e1aaa3 upstream. + +This is strictly related to commit fb7a0d334894 ("mptcp: ensure snd_nxt +is properly initialized on connect"). It turns out that syzkaller can +trigger the retransmit after fallback and before processing any other +incoming packet - so that snd_una is still left uninitialized. + +Address the issue explicitly initializing snd_una together with snd_nxt +and write_seq. + +Suggested-by: Mat Martineau +Fixes: 8fd738049ac3 ("mptcp: fallback in case of simultaneous connect") +Cc: stable@vger.kernel.org +Reported-by: Christoph Paasch +Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/485 +Signed-off-by: Paolo Abeni +Reviewed-by: Mat Martineau +Signed-off-by: Matthieu Baerts (NGI0) +Link: https://lore.kernel.org/r/20240607-upstream-net-20240607-misc-fixes-v1-1-1ab9ddfa3d00@kernel.org +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + net/mptcp/protocol.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/net/mptcp/protocol.c ++++ b/net/mptcp/protocol.c +@@ -3706,6 +3706,7 @@ static int mptcp_connect(struct sock *sk + + WRITE_ONCE(msk->write_seq, subflow->idsn); + WRITE_ONCE(msk->snd_nxt, subflow->idsn); ++ WRITE_ONCE(msk->snd_una, subflow->idsn); + if (likely(!__mptcp_check_fallback(msk))) + MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_MPCAPABLEACTIVE); + diff --git a/queue-6.6/mptcp-pm-inc-rmaddr-mib-counter-once-per-rm_addr-id.patch b/queue-6.6/mptcp-pm-inc-rmaddr-mib-counter-once-per-rm_addr-id.patch new file mode 100644 index 00000000000..01d4390c2ad --- /dev/null +++ b/queue-6.6/mptcp-pm-inc-rmaddr-mib-counter-once-per-rm_addr-id.patch @@ -0,0 +1,67 @@ +From 6a09788c1a66e3d8b04b3b3e7618cc817bb60ae9 Mon Sep 17 00:00:00 2001 +From: YonglongLi +Date: Fri, 7 Jun 2024 17:01:49 +0200 +Subject: mptcp: pm: inc RmAddr MIB counter once per RM_ADDR ID + +From: YonglongLi + +commit 6a09788c1a66e3d8b04b3b3e7618cc817bb60ae9 upstream. + +The RmAddr MIB counter is supposed to be incremented once when a valid +RM_ADDR has been received. Before this patch, it could have been +incremented as many times as the number of subflows connected to the +linked address ID, so it could have been 0, 1 or more than 1. + +The "RmSubflow" is incremented after a local operation. In this case, +it is normal to tied it with the number of subflows that have been +actually removed. + +The "remove invalid addresses" MP Join subtest has been modified to +validate this case. A broadcast IP address is now used instead: the +client will not be able to create a subflow to this address. The +consequence is that when receiving the RM_ADDR with the ID attached to +this broadcast IP address, no subflow linked to this ID will be found. + +Fixes: 7a7e52e38a40 ("mptcp: add RM_ADDR related mibs") +Cc: stable@vger.kernel.org +Co-developed-by: Matthieu Baerts (NGI0) +Signed-off-by: Matthieu Baerts (NGI0) +Signed-off-by: YonglongLi +Signed-off-by: Matthieu Baerts (NGI0) +Link: https://lore.kernel.org/r/20240607-upstream-net-20240607-misc-fixes-v1-2-1ab9ddfa3d00@kernel.org +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + net/mptcp/pm_netlink.c | 5 ++++- + tools/testing/selftests/net/mptcp/mptcp_join.sh | 3 ++- + 2 files changed, 6 insertions(+), 2 deletions(-) + +--- a/net/mptcp/pm_netlink.c ++++ b/net/mptcp/pm_netlink.c +@@ -822,10 +822,13 @@ static void mptcp_pm_nl_rm_addr_or_subfl + spin_lock_bh(&msk->pm.lock); + + removed = true; +- __MPTCP_INC_STATS(sock_net(sk), rm_type); ++ if (rm_type == MPTCP_MIB_RMSUBFLOW) ++ __MPTCP_INC_STATS(sock_net(sk), rm_type); + } + if (rm_type == MPTCP_MIB_RMSUBFLOW) + __set_bit(rm_id ? rm_id : msk->mpc_endpoint_id, msk->pm.id_avail_bitmap); ++ else if (rm_type == MPTCP_MIB_RMADDR) ++ __MPTCP_INC_STATS(sock_net(sk), rm_type); + if (!removed) + continue; + +--- a/tools/testing/selftests/net/mptcp/mptcp_join.sh ++++ b/tools/testing/selftests/net/mptcp/mptcp_join.sh +@@ -2394,7 +2394,8 @@ remove_tests() + pm_nl_set_limits $ns1 3 3 + pm_nl_add_endpoint $ns1 10.0.12.1 flags signal + pm_nl_add_endpoint $ns1 10.0.3.1 flags signal +- pm_nl_add_endpoint $ns1 10.0.14.1 flags signal ++ # broadcast IP: no packet for this address will be received on ns1 ++ pm_nl_add_endpoint $ns1 224.0.0.1 flags signal + pm_nl_set_limits $ns2 3 3 + addr_nr_ns1=-3 speed=10 \ + run_tests $ns1 $ns2 10.0.1.1 diff --git a/queue-6.6/mptcp-pm-update-add_addr-counters-after-connect.patch b/queue-6.6/mptcp-pm-update-add_addr-counters-after-connect.patch new file mode 100644 index 00000000000..6f340928313 --- /dev/null +++ b/queue-6.6/mptcp-pm-update-add_addr-counters-after-connect.patch @@ -0,0 +1,100 @@ +From 40eec1795cc27b076d49236649a29507c7ed8c2d Mon Sep 17 00:00:00 2001 +From: YonglongLi +Date: Fri, 7 Jun 2024 17:01:50 +0200 +Subject: mptcp: pm: update add_addr counters after connect + +From: YonglongLi + +commit 40eec1795cc27b076d49236649a29507c7ed8c2d upstream. + +The creation of new subflows can fail for different reasons. If no +subflow have been created using the received ADD_ADDR, the related +counters should not be updated, otherwise they will never be decremented +for events related to this ID later on. + +For the moment, the number of accepted ADD_ADDR is only decremented upon +the reception of a related RM_ADDR, and only if the remote address ID is +currently being used by at least one subflow. In other words, if no +subflow can be created with the received address, the counter will not +be decremented. In this case, it is then important not to increment +pm.add_addr_accepted counter, and not to modify pm.accept_addr bit. + +Note that this patch does not modify the behaviour in case of failures +later on, e.g. if the MP Join is dropped or rejected. + +The "remove invalid addresses" MP Join subtest has been modified to +validate this case. The broadcast IP address is added before the "valid" +address that will be used to successfully create a subflow, and the +limit is decreased by one: without this patch, it was not possible to +create the last subflow, because: + +- the broadcast address would have been accepted even if it was not + usable: the creation of a subflow to this address results in an error, + +- the limit of 2 accepted ADD_ADDR would have then been reached. + +Fixes: 01cacb00b35c ("mptcp: add netlink-based PM") +Cc: stable@vger.kernel.org +Co-developed-by: Matthieu Baerts (NGI0) +Signed-off-by: Matthieu Baerts (NGI0) +Signed-off-by: YonglongLi +Reviewed-by: Mat Martineau +Signed-off-by: Matthieu Baerts (NGI0) +Link: https://lore.kernel.org/r/20240607-upstream-net-20240607-misc-fixes-v1-3-1ab9ddfa3d00@kernel.org +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + net/mptcp/pm_netlink.c | 16 ++++++++++------ + tools/testing/selftests/net/mptcp/mptcp_join.sh | 4 ++-- + 2 files changed, 12 insertions(+), 8 deletions(-) + +--- a/net/mptcp/pm_netlink.c ++++ b/net/mptcp/pm_netlink.c +@@ -685,6 +685,7 @@ static void mptcp_pm_nl_add_addr_receive + unsigned int add_addr_accept_max; + struct mptcp_addr_info remote; + unsigned int subflows_max; ++ bool sf_created = false; + int i, nr; + + add_addr_accept_max = mptcp_pm_get_add_addr_accept_max(msk); +@@ -712,15 +713,18 @@ static void mptcp_pm_nl_add_addr_receive + if (nr == 0) + return; + +- msk->pm.add_addr_accepted++; +- if (msk->pm.add_addr_accepted >= add_addr_accept_max || +- msk->pm.subflows >= subflows_max) +- WRITE_ONCE(msk->pm.accept_addr, false); +- + spin_unlock_bh(&msk->pm.lock); + for (i = 0; i < nr; i++) +- __mptcp_subflow_connect(sk, &addrs[i], &remote); ++ if (__mptcp_subflow_connect(sk, &addrs[i], &remote) == 0) ++ sf_created = true; + spin_lock_bh(&msk->pm.lock); ++ ++ if (sf_created) { ++ msk->pm.add_addr_accepted++; ++ if (msk->pm.add_addr_accepted >= add_addr_accept_max || ++ msk->pm.subflows >= subflows_max) ++ WRITE_ONCE(msk->pm.accept_addr, false); ++ } + } + + void mptcp_pm_nl_addr_send_ack(struct mptcp_sock *msk) +--- a/tools/testing/selftests/net/mptcp/mptcp_join.sh ++++ b/tools/testing/selftests/net/mptcp/mptcp_join.sh +@@ -2393,10 +2393,10 @@ remove_tests() + if reset "remove invalid addresses"; then + pm_nl_set_limits $ns1 3 3 + pm_nl_add_endpoint $ns1 10.0.12.1 flags signal +- pm_nl_add_endpoint $ns1 10.0.3.1 flags signal + # broadcast IP: no packet for this address will be received on ns1 + pm_nl_add_endpoint $ns1 224.0.0.1 flags signal +- pm_nl_set_limits $ns2 3 3 ++ pm_nl_add_endpoint $ns1 10.0.3.1 flags signal ++ pm_nl_set_limits $ns2 2 2 + addr_nr_ns1=-3 speed=10 \ + run_tests $ns1 $ns2 10.0.1.1 + chk_join_nr 1 1 1 diff --git a/queue-6.6/series b/queue-6.6/series index e7676320e40..41a9165d1e9 100644 --- a/queue-6.6/series +++ b/queue-6.6/series @@ -189,3 +189,10 @@ iio-invensense-fix-odr-switching-to-same-value.patch iio-imu-inv_icm42600-delete-unneeded-update-watermark-call.patch drivers-core-synchronize-really_probe-and-dev_uevent.patch parisc-try-to-fix-random-segmentation-faults-in-package-builds.patch +acpi-x86-force-storaged3enable-on-more-products.patch +x86-mm-numa-use-numa_no_node-when-calling-memblock_set_node.patch +drm-exynos-vidi-fix-memory-leak-in-.get_modes.patch +drm-exynos-hdmi-report-safe-640x480-mode-as-a-fallback-when-no-edid-found.patch +mptcp-ensure-snd_una-is-properly-initialized-on-connect.patch +mptcp-pm-inc-rmaddr-mib-counter-once-per-rm_addr-id.patch +mptcp-pm-update-add_addr-counters-after-connect.patch diff --git a/queue-6.6/x86-mm-numa-use-numa_no_node-when-calling-memblock_set_node.patch b/queue-6.6/x86-mm-numa-use-numa_no_node-when-calling-memblock_set_node.patch new file mode 100644 index 00000000000..0b5a2c2319d --- /dev/null +++ b/queue-6.6/x86-mm-numa-use-numa_no_node-when-calling-memblock_set_node.patch @@ -0,0 +1,53 @@ +From 3ac36aa7307363b7247ccb6f6a804e11496b2b36 Mon Sep 17 00:00:00 2001 +From: Jan Beulich +Date: Wed, 29 May 2024 09:42:05 +0200 +Subject: x86/mm/numa: Use NUMA_NO_NODE when calling memblock_set_node() + +From: Jan Beulich + +commit 3ac36aa7307363b7247ccb6f6a804e11496b2b36 upstream. + +memblock_set_node() warns about using MAX_NUMNODES, see + + e0eec24e2e19 ("memblock: make memblock_set_node() also warn about use of MAX_NUMNODES") + +for details. + +Reported-by: Narasimhan V +Signed-off-by: Jan Beulich +Cc: stable@vger.kernel.org +[bp: commit message] +Signed-off-by: Borislav Petkov (AMD) +Reviewed-by: Mike Rapoport (IBM) +Tested-by: Paul E. McKenney +Link: https://lore.kernel.org/r/20240603141005.23261-1-bp@kernel.org +Link: https://lore.kernel.org/r/abadb736-a239-49e4-ab42-ace7acdd4278@suse.com +Signed-off-by: Mike Rapoport (IBM) +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/mm/numa.c | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +--- a/arch/x86/mm/numa.c ++++ b/arch/x86/mm/numa.c +@@ -523,7 +523,7 @@ static void __init numa_clear_kernel_nod + for_each_reserved_mem_region(mb_region) { + int nid = memblock_get_region_node(mb_region); + +- if (nid != MAX_NUMNODES) ++ if (nid != NUMA_NO_NODE) + node_set(nid, reserved_nodemask); + } + +@@ -643,9 +643,9 @@ static int __init numa_init(int (*init_f + nodes_clear(node_online_map); + memset(&numa_meminfo, 0, sizeof(numa_meminfo)); + WARN_ON(memblock_set_node(0, ULLONG_MAX, &memblock.memory, +- MAX_NUMNODES)); ++ NUMA_NO_NODE)); + WARN_ON(memblock_set_node(0, ULLONG_MAX, &memblock.reserved, +- MAX_NUMNODES)); ++ NUMA_NO_NODE)); + /* In case that parsing SRAT failed. */ + WARN_ON(memblock_clear_hotplug(0, ULLONG_MAX)); + numa_reset_distance();