From: Greg Kroah-Hartman Date: Mon, 17 Jun 2024 18:21:42 +0000 (+0200) Subject: 5.15-stable patches X-Git-Tag: v6.1.95~96 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=4ebe1fdcc5572cf097127182938b8f620ac78de1;p=thirdparty%2Fkernel%2Fstable-queue.git 5.15-stable patches 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 x86-mm-numa-use-numa_no_node-when-calling-memblock_set_node.patch --- diff --git a/queue-5.15/drm-exynos-hdmi-report-safe-640x480-mode-as-a-fallback-when-no-edid-found.patch b/queue-5.15/drm-exynos-hdmi-report-safe-640x480-mode-as-a-fallback-when-no-edid-found.patch new file mode 100644 index 00000000000..6de4c1e921c --- /dev/null +++ b/queue-5.15/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 = !drm_detect_hdmi_monitor(edid); + 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-5.15/drm-exynos-vidi-fix-memory-leak-in-.get_modes.patch b/queue-5.15/drm-exynos-vidi-fix-memory-leak-in-.get_modes.patch new file mode 100644 index 00000000000..4a7b6b22e19 --- /dev/null +++ b/queue-5.15/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 +@@ -308,6 +308,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 +@@ -327,7 +328,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-5.15/mptcp-ensure-snd_una-is-properly-initialized-on-connect.patch b/queue-5.15/mptcp-ensure-snd_una-is-properly-initialized-on-connect.patch new file mode 100644 index 00000000000..8ab11098aa7 --- /dev/null +++ b/queue-5.15/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 +@@ -3398,6 +3398,7 @@ static int mptcp_stream_connect(struct s + + 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(sock->sk), MPTCP_MIB_MPCAPABLEACTIVE); + diff --git a/queue-5.15/series b/queue-5.15/series index 83649a5684d..cce32c8f8c4 100644 --- a/queue-5.15/series +++ b/queue-5.15/series @@ -138,3 +138,7 @@ 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 diff --git a/queue-5.15/x86-mm-numa-use-numa_no_node-when-calling-memblock_set_node.patch b/queue-5.15/x86-mm-numa-use-numa_no_node-when-calling-memblock_set_node.patch new file mode 100644 index 00000000000..e6b07ea3d6d --- /dev/null +++ b/queue-5.15/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 +@@ -522,7 +522,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); + } + +@@ -642,9 +642,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();