]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/commitdiff
6.1-stable patches
authorGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Mon, 17 Jun 2024 18:22:10 +0000 (20:22 +0200)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Mon, 17 Jun 2024 18:22:10 +0000 (20:22 +0200)
added patches:
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
x86-mm-numa-use-numa_no_node-when-calling-memblock_set_node.patch

queue-6.1/drm-exynos-hdmi-report-safe-640x480-mode-as-a-fallback-when-no-edid-found.patch [new file with mode: 0644]
queue-6.1/drm-exynos-vidi-fix-memory-leak-in-.get_modes.patch [new file with mode: 0644]
queue-6.1/mptcp-ensure-snd_una-is-properly-initialized-on-connect.patch [new file with mode: 0644]
queue-6.1/mptcp-pm-inc-rmaddr-mib-counter-once-per-rm_addr-id.patch [new file with mode: 0644]
queue-6.1/series
queue-6.1/x86-mm-numa-use-numa_no_node-when-calling-memblock_set_node.patch [new file with mode: 0644]

diff --git a/queue-6.1/drm-exynos-hdmi-report-safe-640x480-mode-as-a-fallback-when-no-edid-found.patch b/queue-6.1/drm-exynos-hdmi-report-safe-640x480-mode-as-a-fallback-when-no-edid-found.patch
new file mode 100644 (file)
index 0000000..88acadb
--- /dev/null
@@ -0,0 +1,128 @@
+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)
diff --git a/queue-6.1/drm-exynos-vidi-fix-memory-leak-in-.get_modes.patch b/queue-6.1/drm-exynos-vidi-fix-memory-leak-in-.get_modes.patch
new file mode 100644 (file)
index 0000000..b60884c
--- /dev/null
@@ -0,0 +1,42 @@
+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 = {
diff --git a/queue-6.1/mptcp-ensure-snd_una-is-properly-initialized-on-connect.patch b/queue-6.1/mptcp-ensure-snd_una-is-properly-initialized-on-connect.patch
new file mode 100644 (file)
index 0000000..4fae615
--- /dev/null
@@ -0,0 +1,42 @@
+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
+@@ -3757,6 +3757,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.1/mptcp-pm-inc-rmaddr-mib-counter-once-per-rm_addr-id.patch b/queue-6.1/mptcp-pm-inc-rmaddr-mib-counter-once-per-rm_addr-id.patch
new file mode 100644 (file)
index 0000000..8b16278
--- /dev/null
@@ -0,0 +1,67 @@
+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
+@@ -820,10 +820,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
+@@ -2344,7 +2344,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
+               run_tests $ns1 $ns2 10.0.1.1 0 -3 0 speed_10
+               chk_join_nr 1 1 1
index 34d520263aa678273aa74b33faf0e8a90533c9e4..4c9b9c8262d4afc0da05faf160d69b7ff64e8f4f 100644 (file)
@@ -166,3 +166,8 @@ iio-adc-ad9467-fix-scan-type-sign.patch
 iio-dac-ad5592r-fix-temperature-channel-scaling-value.patch
 iio-imu-inv_icm42600-delete-unneeded-update-watermark-call.patch
 drivers-core-synchronize-really_probe-and-dev_uevent.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
diff --git a/queue-6.1/x86-mm-numa-use-numa_no_node-when-calling-memblock_set_node.patch b/queue-6.1/x86-mm-numa-use-numa_no_node-when-calling-memblock_set_node.patch
new file mode 100644 (file)
index 0000000..0b5a2c2
--- /dev/null
@@ -0,0 +1,53 @@
+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
+@@ -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();