--- /dev/null
+From e79a10652bbd320649da705ca1ea0c04351af403 Mon Sep 17 00:00:00 2001
+From: Mario Limonciello <mario.limonciello@amd.com>
+Date: Thu, 9 May 2024 13:45:02 -0500
+Subject: ACPI: x86: Force StorageD3Enable on more products
+
+From: Mario Limonciello <mario.limonciello@amd.com>
+
+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 <stable@vger.kernel.org>
+Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
+Acked-by: Hans de Goede <hdegoede@redhat.com>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+@@ -197,16 +197,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.
+ *
+@@ -219,19 +219,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;
+ }
+
+ /*
--- /dev/null
+From 799d4b392417ed6889030a5b2335ccb6dcf030ab Mon Sep 17 00:00:00 2001
+From: Marek Szyprowski <m.szyprowski@samsung.com>
+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 <m.szyprowski@samsung.com>
+
+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): [<c01a96e8>] vprintk_emit+0x308/0x33c
+hardirqs last disabled at (82368): [<c01a969c>] vprintk_emit+0x2bc/0x33c
+softirqs last enabled at (81614): [<c0101644>] __do_softirq+0x320/0x500
+softirqs last disabled at (81609): [<c012dfe0>] __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 <m.szyprowski@samsung.com>
+Signed-off-by: Inki Dae <inki.dae@samsung.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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)
--- /dev/null
+From 38e3825631b1f314b21e3ade00b5a4d737eb054e Mon Sep 17 00:00:00 2001
+From: Jani Nikula <jani.nikula@intel.com>
+Date: Thu, 30 May 2024 13:01:51 +0300
+Subject: drm/exynos/vidi: fix memory leak in .get_modes()
+
+From: Jani Nikula <jani.nikula@intel.com>
+
+commit 38e3825631b1f314b21e3ade00b5a4d737eb054e upstream.
+
+The duplicated EDID is never freed. Fix it.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Jani Nikula <jani.nikula@intel.com>
+Signed-off-by: Inki Dae <inki.dae@samsung.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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 = {
--- /dev/null
+From e0eec24e2e199873f43df99ec39773ad3af2bff7 Mon Sep 17 00:00:00 2001
+From: Jan Beulich <jbeulich@suse.com>
+Date: Wed, 29 May 2024 09:39:10 +0200
+Subject: memblock: make memblock_set_node() also warn about use of MAX_NUMNODES
+
+From: Jan Beulich <jbeulich@suse.com>
+
+commit e0eec24e2e199873f43df99ec39773ad3af2bff7 upstream.
+
+On an (old) x86 system with SRAT just covering space above 4Gb:
+
+ ACPI: SRAT: Node 0 PXM 0 [mem 0x100000000-0xfffffffff] hotplug
+
+the commit referenced below leads to this NUMA configuration no longer
+being refused by a CONFIG_NUMA=y kernel (previously
+
+ NUMA: nodes only cover 6144MB of your 8185MB e820 RAM. Not used.
+ No NUMA configuration found
+ Faking a node at [mem 0x0000000000000000-0x000000027fffffff]
+
+was seen in the log directly after the message quoted above), because of
+memblock_validate_numa_coverage() checking for NUMA_NO_NODE (only). This
+in turn led to memblock_alloc_range_nid()'s warning about MAX_NUMNODES
+triggering, followed by a NULL deref in memmap_init() when trying to
+access node 64's (NODE_SHIFT=6) node data.
+
+To compensate said change, make memblock_set_node() warn on and adjust
+a passed in value of MAX_NUMNODES, just like various other functions
+already do.
+
+Fixes: ff6c3d81f2e8 ("NUMA: optimize detection of memory with no node id assigned by firmware")
+Signed-off-by: Jan Beulich <jbeulich@suse.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/1c8a058c-5365-4f27-a9f1-3aeb7fb3e7b2@suse.com
+Signed-off-by: Mike Rapoport (IBM) <rppt@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/memblock.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/mm/memblock.c
++++ b/mm/memblock.c
+@@ -1339,6 +1339,10 @@ int __init_memblock memblock_set_node(ph
+ int start_rgn, end_rgn;
+ int i, ret;
+
++ if (WARN_ONCE(nid == MAX_NUMNODES,
++ "Usage of MAX_NUMNODES is deprecated. Use NUMA_NO_NODE instead\n"))
++ nid = NUMA_NO_NODE;
++
+ ret = memblock_isolate_range(type, base, size, &start_rgn, &end_rgn);
+ if (ret)
+ return ret;
--- /dev/null
+From 8031b58c3a9b1db3ef68b3bd749fbee2e1e1aaa3 Mon Sep 17 00:00:00 2001
+From: Paolo Abeni <pabeni@redhat.com>
+Date: Fri, 7 Jun 2024 17:01:48 +0200
+Subject: mptcp: ensure snd_una is properly initialized on connect
+
+From: Paolo Abeni <pabeni@redhat.com>
+
+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 <martineau@kernel.org>
+Fixes: 8fd738049ac3 ("mptcp: fallback in case of simultaneous connect")
+Cc: stable@vger.kernel.org
+Reported-by: Christoph Paasch <cpaasch@apple.com>
+Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/485
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Reviewed-by: Mat Martineau <martineau@kernel.org>
+Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+Link: https://lore.kernel.org/r/20240607-upstream-net-20240607-misc-fixes-v1-1-1ab9ddfa3d00@kernel.org
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/mptcp/protocol.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/net/mptcp/protocol.c
++++ b/net/mptcp/protocol.c
+@@ -3731,6 +3731,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);
+
--- /dev/null
+From 6a09788c1a66e3d8b04b3b3e7618cc817bb60ae9 Mon Sep 17 00:00:00 2001
+From: YonglongLi <liyonglong@chinatelecom.cn>
+Date: Fri, 7 Jun 2024 17:01:49 +0200
+Subject: mptcp: pm: inc RmAddr MIB counter once per RM_ADDR ID
+
+From: YonglongLi <liyonglong@chinatelecom.cn>
+
+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) <matttbe@kernel.org>
+Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+Signed-off-by: YonglongLi <liyonglong@chinatelecom.cn>
+Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+Link: https://lore.kernel.org/r/20240607-upstream-net-20240607-misc-fixes-v1-2-1ab9ddfa3d00@kernel.org
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+@@ -813,10 +813,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
+@@ -2359,7 +2359,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
--- /dev/null
+From 40eec1795cc27b076d49236649a29507c7ed8c2d Mon Sep 17 00:00:00 2001
+From: YonglongLi <liyonglong@chinatelecom.cn>
+Date: Fri, 7 Jun 2024 17:01:50 +0200
+Subject: mptcp: pm: update add_addr counters after connect
+
+From: YonglongLi <liyonglong@chinatelecom.cn>
+
+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) <matttbe@kernel.org>
+Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+Signed-off-by: YonglongLi <liyonglong@chinatelecom.cn>
+Reviewed-by: Mat Martineau <martineau@kernel.org>
+Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+Link: https://lore.kernel.org/r/20240607-upstream-net-20240607-misc-fixes-v1-3-1ab9ddfa3d00@kernel.org
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+@@ -676,6 +676,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);
+@@ -703,15 +704,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
+@@ -2358,10 +2358,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
parisc-try-to-fix-random-segmentation-faults-in-package-builds.patch
ras-amd-atl-fix-mi300-bank-hash.patch
ras-amd-atl-use-system-settings-for-mi300-dram-to-normalized-address-translation.patch
+acpi-x86-force-storaged3enable-on-more-products.patch
+thermal-acpi-invalidate-trip-points-with-temperature-of-0-or-below.patch
+x86-mm-numa-use-numa_no_node-when-calling-memblock_set_node.patch
+memblock-make-memblock_set_node-also-warn-about-use-of-max_numnodes.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
--- /dev/null
+From 7f18bd49cb6b6a3ab6d860fefccdc94f2a247db0 Mon Sep 17 00:00:00 2001
+From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
+Date: Thu, 6 Jun 2024 20:27:30 +0200
+Subject: thermal: ACPI: Invalidate trip points with temperature of 0 or below
+
+From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+
+commit 7f18bd49cb6b6a3ab6d860fefccdc94f2a247db0 upstream.
+
+It is reported that commit 950210887670 ("thermal: core: Drop
+trips_disabled bitmask") causes the maximum frequency of CPUs to drop
+further down with every system sleep-wake cycle on Intel Core i7-4710HQ.
+
+This turns out to be due to a trip point whose temperature is equal to 0
+degrees Celsius which is acted on every time the system wakes from sleep.
+
+Before commit 950210887670 this trip point would be disabled wia the
+trips_disabled bitmask, but now it is treated as a valid one.
+
+Since ACPI thermal control is generally about protection against
+overheating, trip points with temperature of 0 centigrade or below are
+not particularly useful there, so initialize them all as invalid which
+fixes the problem at hand.
+
+Fixes: 950210887670 ("thermal: core: Drop trips_disabled bitmask")
+Closes: https://lore.kernel.org/linux-pm/3f71747b-f852-4ee0-b384-cf46b2aefa3f@gmx.com
+Reported-by: Tibor Billes <tbilles@gmx.com>
+Tested-by: Tibor Billes <tbilles@gmx.com>
+Cc: 6.7+ <stable@vger.kernel.org> # 6.7+
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/acpi/thermal.c | 8 +++++++-
+ 1 file changed, 7 insertions(+), 1 deletion(-)
+
+--- a/drivers/acpi/thermal.c
++++ b/drivers/acpi/thermal.c
+@@ -168,11 +168,17 @@ static int acpi_thermal_get_polling_freq
+
+ static int acpi_thermal_temp(struct acpi_thermal *tz, int temp_deci_k)
+ {
++ int temp;
++
+ if (temp_deci_k == THERMAL_TEMP_INVALID)
+ return THERMAL_TEMP_INVALID;
+
+- return deci_kelvin_to_millicelsius_with_offset(temp_deci_k,
++ temp = deci_kelvin_to_millicelsius_with_offset(temp_deci_k,
+ tz->kelvin_offset);
++ if (temp <= 0)
++ return THERMAL_TEMP_INVALID;
++
++ return temp;
+ }
+
+ static bool acpi_thermal_trip_valid(struct acpi_thermal_trip *acpi_trip)
--- /dev/null
+From 3ac36aa7307363b7247ccb6f6a804e11496b2b36 Mon Sep 17 00:00:00 2001
+From: Jan Beulich <jbeulich@suse.com>
+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 <jbeulich@suse.com>
+
+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 <Narasimhan.V@amd.com>
+Signed-off-by: Jan Beulich <jbeulich@suse.com>
+Cc: stable@vger.kernel.org
+[bp: commit message]
+Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
+Reviewed-by: Mike Rapoport (IBM) <rppt@kernel.org>
+Tested-by: Paul E. McKenney <paulmck@kernel.org>
+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) <rppt@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+@@ -493,7 +493,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);
+ }
+
+@@ -614,9 +614,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();
projects / thirdparty / kernel / stable-queue.git / commitdiff
