kernel/linux.git, branch v6.12.5

Linux 6.12.5

2024-12-14T19:04:17+00:00

Link: https://lore.kernel.org/r/20241212144306.641051666@linuxfoundation.org Tested-by: Luna Jernberg Tested-by: Ronald Warsow Tested-by: Salvatore Bonaccorso Tested-by: Christian Heusel Tested-by: Peter Schneider Tested-by: Jon Hunter Tested-by: Mark Brown Tested-by: Shuah Khan Tested-by: SeongJae Park Link: https://lore.kernel.org/r/20241213145925.077514874@linuxfoundation.org Tested-by: Ronald Warsow Tested-by: Luna Jernberg Tested-by: Ron Economos Tested-by: Willy Tarreau Tested-by: Takeshi Ogasawara Tested-by: kernelci.org bot Tested-by: Linux Kernel Functional Testing Tested-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman

softirq: Allow raising SCHED_SOFTIRQ from SMP-call-function on RT kernel

2024-12-14T19:04:16+00:00

commit 6675ce20046d149e1e1ffe7e9577947dee17aad5 upstream. do_softirq_post_smp_call_flush() on PREEMPT_RT kernels carries a WARN_ON_ONCE() for any SOFTIRQ being raised from an SMP-call-function. Since do_softirq_post_smp_call_flush() is called with preempt disabled, raising a SOFTIRQ during flush_smp_call_function_queue() can lead to longer preempt disabled sections. Since commit b2a02fc43a1f ("smp: Optimize send_call_function_single_ipi()") IPIs to an idle CPU in TIF_POLLING_NRFLAG mode can be optimized out by instead setting TIF_NEED_RESCHED bit in idle task's thread_info and relying on the flush_smp_call_function_queue() in the idle-exit path to run the SMP-call-function. To trigger an idle load balancing, the scheduler queues nohz_csd_function() responsible for triggering an idle load balancing on a target nohz idle CPU and sends an IPI. Only now, this IPI is optimized out and the SMP-call-function is executed from flush_smp_call_function_queue() in do_idle() which can raise a SCHED_SOFTIRQ to trigger the balancing. So far, this went undetected since, the need_resched() check in nohz_csd_function() would make it bail out of idle load balancing early as the idle thread does not clear TIF_POLLING_NRFLAG before calling flush_smp_call_function_queue(). The need_resched() check was added with the intent to catch a new task wakeup, however, it has recently discovered to be unnecessary and will be removed in the subsequent commit after which nohz_csd_function() can raise a SCHED_SOFTIRQ from flush_smp_call_function_queue() to trigger an idle load balance on an idle target in TIF_POLLING_NRFLAG mode. nohz_csd_function() bails out early if "idle_cpu()" check for the target CPU, and does not lock the target CPU's rq until the very end, once it has found tasks to run on the CPU and will not inhibit the wakeup of, or running of a newly woken up higher priority task. Account for this and prevent a WARN_ON_ONCE() when SCHED_SOFTIRQ is raised from flush_smp_call_function_queue(). Signed-off-by: K Prateek Nayak Signed-off-by: Peter Zijlstra (Intel) Link: https://lore.kernel.org/r/20241119054432.6405-2-kprateek.nayak@amd.com Signed-off-by: Greg Kroah-Hartman

clocksource: Make negative motion detection more robust

2024-12-14T19:04:16+00:00

commit 76031d9536a076bf023bedbdb1b4317fc801dd67 upstream. Guenter reported boot stalls on a emulated ARM 32-bit platform, which has a 24-bit wide clocksource. It turns out that the calculated maximal idle time, which limits idle sleeps to prevent clocksource wrap arounds, is close to the point where the negative motion detection triggers. max_idle_ns: 597268854 ns negative motion tripping point: 671088640 ns If the idle wakeup is delayed beyond that point, the clocksource advances far enough to trigger the negative motion detection. This prevents the clock to advance and in the worst case the system stalls completely if the consecutive sleeps based on the stale clock are delayed as well. Cure this by calculating a more robust cut-off value for negative motion, which covers 87.5% of the actual clocksource counter width. Compare the delta against this value to catch negative motion. This is specifically for clock sources with a small counter width as their wrap around time is close to the half counter width. For clock sources with wide counters this is not a problem because the maximum idle time is far from the half counter width due to the math overflow protection constraints. For the case at hand this results in a tripping point of 1174405120ns. Note, that this cannot prevent issues when the delay exceeds the 87.5% margin, but that's not different from the previous unchecked version which allowed arbitrary time jumps. Systems with small counter width are prone to invalid results, but this problem is unlikely to be seen on real hardware. If such a system completely stalls for more than half a second, then there are other more urgent problems than the counter wrapping around. Fixes: c163e40af9b2 ("timekeeping: Always check for negative motion") Reported-by: Guenter Roeck Signed-off-by: Thomas Gleixner Tested-by: Guenter Roeck Link: https://lore.kernel.org/all/8734j5ul4x.ffs@tglx Closes: https://lore.kernel.org/all/387b120b-d68a-45e8-b6ab-768cd95d11c2@roeck-us.net Signed-off-by: Greg Kroah-Hartman

timekeeping: Remove CONFIG_DEBUG_TIMEKEEPING

2024-12-14T19:04:16+00:00

commit d44d26987bb3df6d76556827097fc9ce17565cb8 upstream. Since 135225a363ae timekeeping_cycles_to_ns() handles large offsets which would lead to 64bit multiplication overflows correctly. It's also protected against negative motion of the clocksource unconditionally, which was exclusive to x86 before. timekeeping_advance() handles large offsets already correctly. That means the value of CONFIG_DEBUG_TIMEKEEPING which analyzed these cases is very close to zero. Remove all of it. Signed-off-by: Thomas Gleixner Acked-by: John Stultz Link: https://lore.kernel.org/all/20241031120328.536010148@linutronix.de Signed-off-by: Greg Kroah-Hartman

ALSA: hda/realtek: Fix spelling mistake "Firelfy" -> "Firefly"

2024-12-14T19:04:16+00:00

commit 20c3b3e5f2641eff3d85f33e6a468ac052b169bd upstream. There is a spelling mistake in a literal string in the alc269_fixup_tbl quirk table. Fix it. Fixes: 0d08f0eec961 ("ALSA: hda/realtek: fix micmute LEDs don't work on HP Laptops") Signed-off-by: Colin Ian King Link: https://patch.msgid.link/20241205102833.476190-1-colin.i.king@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman

s390/pci: Fix leak of struct zpci_dev when zpci_add_device() fails

2024-12-14T19:04:16+00:00

commit 48796104c864cf4dafa80bd8c2ce88f9c92a65ea upstream. Prior to commit 0467cdde8c43 ("s390/pci: Sort PCI functions prior to creating virtual busses") the IOMMU was initialized and the device was registered as part of zpci_create_device() with the struct zpci_dev freed if either resulted in an error. With that commit this was moved into a separate function called zpci_add_device(). While this new function logs when adding failed, it expects the caller not to use and to free the struct zpci_dev on error. This difference between it and zpci_create_device() was missed while changing the callers and the incompletely initialized struct zpci_dev may get used in zpci_scan_configured_device in the error path. This then leads to a crash due to the device not being registered with the zbus. It was also not freed in this case. Fix this by handling the error return of zpci_add_device(). Since in this case the zdev was not added to the zpci_list it can simply be discarded and freed. Also make this more explicit by moving the kref_init() into zpci_add_device() and document that zpci_zdev_get()/zpci_zdev_put() must be used after adding. Cc: stable@vger.kernel.org Fixes: 0467cdde8c43 ("s390/pci: Sort PCI functions prior to creating virtual busses") Reviewed-by: Gerd Bayer Reviewed-by: Matthew Rosato Signed-off-by: Niklas Schnelle Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman

Revert "drm/amd/display: parse umc_info or vram_info based on ASIC"

2024-12-14T19:04:15+00:00

commit 3c2296b1eec55b50c64509ba15406142d4a958dc upstream. This reverts commit 2551b4a321a68134360b860113dd460133e856e5. This was not the root cause. Revert. Link: https://gitlab.freedesktop.org/drm/amd/-/issues/3678 Reviewed-by: Harry Wentland Signed-off-by: Alex Deucher Cc: aurabindo.pillai@amd.com Cc: hamishclaxton@gmail.com Signed-off-by: Greg Kroah-Hartman

ALSA: hda: Fix build error without CONFIG_SND_DEBUG

2024-12-14T19:04:15+00:00

commit 0ddf2784d6c29e59409a62b8f32dc5abe56135a4 upstream. The macro should have been defined without setting the non-existing name field in the case of CONFIG_SND_DEBUG=n. Reported-by: Stephen Rothwell Closes: https://lore.kernel.org/20241011131046.5eb3905a@canb.auug.org.au Fixes: 5b1913a79c3e ("ALSA: hda: Use own quirk lookup helper") Link: https://patch.msgid.link/20241011072152.14657-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman

drm/amdgpu: rework resume handling for display (v2)

2024-12-14T19:04:15+00:00

commit 73dae652dcac776296890da215ee7dec357a1032 upstream. Split resume into a 3rd step to handle displays when DCC is enabled on DCN 4.0.1. Move display after the buffer funcs have been re-enabled so that the GPU will do the move and properly set the DCC metadata for DCN. v2: fix fence irq resume ordering Reviewed-by: Christian König Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org # 6.11.x Signed-off-by: Greg Kroah-Hartman

ASoC: Intel: avs: Fix return status of avs_pcm_hw_constraints_init()

2024-12-14T19:04:15+00:00

commit a0aae96be5ffc5b456ca07bfe1385b721c20e184 upstream. Check for return code from avs_pcm_hw_constraints_init() in avs_dai_fe_startup() only checks if value is different from 0. Currently function can return positive value, change it to return 0 on success. Reviewed-by: Cezary Rojewski Signed-off-by: Amadeusz Sławiński I've observed KASAN on our setups and while patch itself is correct regardless. Problem seems to be caused by recent changes to rates, as this started happening after recent patchsets and doesn't reproduce with those reverted https://lore.kernel.org/linux-sound/20240905-alsa-12-24-128-v1-0-8371948d3921@baylibre.com/ https://lore.kernel.org/linux-sound/20240911135756.24434-1-tiwai@suse.de/ I've tested using Mark tree, where they are both applied and for some reason snd_pcm_hw_constraint_minmax() started returning positive value, while previously it returned 0. I'm bit worried if it signals some potential deeper problem regarding constraints with above changes. Link: https://patch.msgid.link/20241010112008.545526-1-amadeuszx.slawinski@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman