From: Greg Kroah-Hartman Date: Mon, 24 Feb 2025 13:18:37 +0000 (+0100) Subject: 6.13-stable patches X-Git-Tag: v6.6.80~16 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=9a6238c9c43908e06a6e64b5bea5733ec4969363;p=thirdparty%2Fkernel%2Fstable-queue.git 6.13-stable patches added patches: drm-select-drm_kms_helper-from-drm_gem_shmem_helper.patch net-pse-pd-fix-deadlock-in-current-limit-functions.patch tracing-fix-using-ret-variable-in-tracing_set_tracer.patch --- diff --git a/queue-6.13/drm-select-drm_kms_helper-from-drm_gem_shmem_helper.patch b/queue-6.13/drm-select-drm_kms_helper-from-drm_gem_shmem_helper.patch new file mode 100644 index 0000000000..79bb0a3de6 --- /dev/null +++ b/queue-6.13/drm-select-drm_kms_helper-from-drm_gem_shmem_helper.patch @@ -0,0 +1,69 @@ +From c40ca9ef7c5c9bbb0d2f7774c87417cc4f1713bf Mon Sep 17 00:00:00 2001 +From: Arnd Bergmann +Date: Wed, 22 Jan 2025 10:02:03 +0100 +Subject: drm: select DRM_KMS_HELPER from DRM_GEM_SHMEM_HELPER + +From: Arnd Bergmann + +commit c40ca9ef7c5c9bbb0d2f7774c87417cc4f1713bf upstream. + +In the combination of DRM_KMS_HELPER=m, DRM_GEM_SHMEM_HELPER=y, DRM_FBDEV_EMULATION=y, +The shmem code fails to link against the KMS helpers: + +x86_64-linux-ld: vmlinux.o: in function `drm_fbdev_shmem_driver_fbdev_probe': +(.text+0xeec601): undefined reference to `drm_fb_helper_alloc_info' +x86_64-linux-ld: (.text+0xeec633): undefined reference to `drm_fb_helper_fill_info' +x86_64-linux-ld: vmlinux.o: in function `drm_fbdev_shmem_get_page': +drm_fbdev_shmem.c:(.text+0xeec7d2): undefined reference to `drm_gem_fb_get_obj' +x86_64-linux-ld: vmlinux.o: in function `drm_fbdev_shmem_fb_mmap': +drm_fbdev_shmem.c:(.text+0xeec9f6): undefined reference to `drm_gem_fb_get_obj' +x86_64-linux-ld: vmlinux.o: in function `drm_fbdev_shmem_defio_imageblit': +(.rodata+0x5b2288): undefined reference to `drm_fb_helper_check_var' +x86_64-linux-ld: (.rodata+0x5b2290): undefined reference to `drm_fb_helper_set_par' + +This can happen for a number of device drivers that select DRM_GEM_SHMEM_HELPER +without also selecting DRM_KMS_HELPER. To work around this, add another select +that forces DRM_KMS_HELPER to be built-in rather than a loadable module, but +only if FBDEV emulation is also enabled. DRM_TTM_HELPER and DRM_GEM_DMA_HELPER +look like they have the same problem in theory even if there is no possible +configuration that shows it. For consistency, do the same change to those. + +Closes: https://lore.kernel.org/all/20250121-greedy-flounder-of-abundance-4d2ee8-mkl@pengutronix.de +Reported-by: Marc Kleine-Budde +Tested-by: Marc Kleine-Budde +Reviewed-by: Thomas Zimmermann +Signed-off-by: Arnd Bergmann +Signed-off-by: Thomas Zimmermann +Link: https://patchwork.freedesktop.org/patch/msgid/20250122090211.3161186-1-arnd@kernel.org +Cc: NoisyCoil +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/Kconfig | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/drivers/gpu/drm/Kconfig ++++ b/drivers/gpu/drm/Kconfig +@@ -359,6 +359,7 @@ config DRM_TTM_HELPER + tristate + depends on DRM + select DRM_TTM ++ select DRM_KMS_HELPER if DRM_FBDEV_EMULATION + select FB_CORE if DRM_FBDEV_EMULATION + select FB_SYSMEM_HELPERS_DEFERRED if DRM_FBDEV_EMULATION + help +@@ -367,6 +368,7 @@ config DRM_TTM_HELPER + config DRM_GEM_DMA_HELPER + tristate + depends on DRM ++ select DRM_KMS_HELPER if DRM_FBDEV_EMULATION + select FB_CORE if DRM_FBDEV_EMULATION + select FB_DMAMEM_HELPERS_DEFERRED if DRM_FBDEV_EMULATION + help +@@ -375,6 +377,7 @@ config DRM_GEM_DMA_HELPER + config DRM_GEM_SHMEM_HELPER + tristate + depends on DRM && MMU ++ select DRM_KMS_HELPER if DRM_FBDEV_EMULATION + select FB_CORE if DRM_FBDEV_EMULATION + select FB_SYSMEM_HELPERS_DEFERRED if DRM_FBDEV_EMULATION + help diff --git a/queue-6.13/net-pse-pd-fix-deadlock-in-current-limit-functions.patch b/queue-6.13/net-pse-pd-fix-deadlock-in-current-limit-functions.patch new file mode 100644 index 0000000000..f307721135 --- /dev/null +++ b/queue-6.13/net-pse-pd-fix-deadlock-in-current-limit-functions.patch @@ -0,0 +1,45 @@ +From 488fb6effe03e20f38d34da7425de77bbd3e2665 Mon Sep 17 00:00:00 2001 +From: Kory Maincent +Date: Wed, 12 Feb 2025 16:17:51 +0100 +Subject: net: pse-pd: Fix deadlock in current limit functions + +From: Kory Maincent + +commit 488fb6effe03e20f38d34da7425de77bbd3e2665 upstream. + +Fix a deadlock in pse_pi_get_current_limit and pse_pi_set_current_limit +caused by consecutive mutex_lock calls. One in the function itself and +another in pse_pi_get_voltage. + +Resolve the issue by using the unlocked version of pse_pi_get_voltage +instead. + +Fixes: e0a5e2bba38a ("net: pse-pd: Use power limit at driver side instead of current limit") +Signed-off-by: Kory Maincent +Link: https://patch.msgid.link/20250212151751.1515008-1-kory.maincent@bootlin.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/pse-pd/pse_core.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/net/pse-pd/pse_core.c ++++ b/drivers/net/pse-pd/pse_core.c +@@ -309,7 +309,7 @@ static int pse_pi_get_current_limit(stru + goto out; + mW = ret; + +- ret = pse_pi_get_voltage(rdev); ++ ret = _pse_pi_get_voltage(rdev); + if (!ret) { + dev_err(pcdev->dev, "Voltage null\n"); + ret = -ERANGE; +@@ -346,7 +346,7 @@ static int pse_pi_set_current_limit(stru + + id = rdev_get_id(rdev); + mutex_lock(&pcdev->lock); +- ret = pse_pi_get_voltage(rdev); ++ ret = _pse_pi_get_voltage(rdev); + if (!ret) { + dev_err(pcdev->dev, "Voltage null\n"); + ret = -ERANGE; diff --git a/queue-6.13/tracing-fix-using-ret-variable-in-tracing_set_tracer.patch b/queue-6.13/tracing-fix-using-ret-variable-in-tracing_set_tracer.patch new file mode 100644 index 0000000000..abdcc02abe --- /dev/null +++ b/queue-6.13/tracing-fix-using-ret-variable-in-tracing_set_tracer.patch @@ -0,0 +1,47 @@ +From 22bec11a569983f39c6061cb82279e7de9e3bdfc Mon Sep 17 00:00:00 2001 +From: Steven Rostedt +Date: Mon, 6 Jan 2025 11:11:43 -0500 +Subject: tracing: Fix using ret variable in tracing_set_tracer() + +From: Steven Rostedt + +commit 22bec11a569983f39c6061cb82279e7de9e3bdfc upstream. + +When the function tracing_set_tracer() switched over to using the guard() +infrastructure, it did not need to save the 'ret' variable and would just +return the value when an error arised, instead of setting ret and jumping +to an out label. + +When CONFIG_TRACER_SNAPSHOT is enabled, it had code that expected the +"ret" variable to be initialized to zero and had set 'ret' while holding +an arch_spin_lock() (not used by guard), and then upon releasing the lock +it would check 'ret' and exit if set. But because ret was only set when an +error occurred while holding the locks, 'ret' would be used uninitialized +if there was no error. The code in the CONFIG_TRACER_SNAPSHOT block should +be self contain. Make sure 'ret' is also set when no error occurred. + +Cc: Mathieu Desnoyers +Link: https://lore.kernel.org/20250106111143.2f90ff65@gandalf.local.home +Reported-by: kernel test robot +Reported-by: Dan Carpenter +Closes: https://lore.kernel.org/r/202412271654.nJVBuwmF-lkp@intel.com/ +Fixes: d33b10c0c73ad ("tracing: Switch trace.c code over to use guard()") +Signed-off-by: Steven Rostedt (Google) +Acked-by: Masami Hiramatsu (Google) +Signed-off-by: Greg Kroah-Hartman +--- + kernel/trace/trace.c | 3 +-- + 1 file changed, 1 insertion(+), 2 deletions(-) + +--- a/kernel/trace/trace.c ++++ b/kernel/trace/trace.c +@@ -6102,8 +6102,7 @@ int tracing_set_tracer(struct trace_arra + if (t->use_max_tr) { + local_irq_disable(); + arch_spin_lock(&tr->max_lock); +- if (tr->cond_snapshot) +- ret = -EBUSY; ++ ret = tr->cond_snapshot ? -EBUSY : 0; + arch_spin_unlock(&tr->max_lock); + local_irq_enable(); + if (ret)