From: Greg Kroah-Hartman Date: Tue, 4 Mar 2025 17:14:35 +0000 (+0100) Subject: 6.6-stable patches X-Git-Tag: v6.6.81~24 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=8da4493fb6644d8e512e9490aa574b1bbd7d61a6;p=thirdparty%2Fkernel%2Fstable-queue.git 6.6-stable patches added patches: alsa-hda-realtek-fix-microphone-regression-on-asus-n705ud.patch alsa-usb-audio-re-add-sample-rate-quirk-for-pioneer-djm-900nxs2.patch drm-amd-display-disable-psr-su-on-edp-panels.patch drm-amd-display-fix-hpd-after-gpu-reset.patch ftrace-avoid-potential-division-by-zero-in-function_stat_show.patch i2c-ls2x-fix-frequency-division-register-access.patch i2c-npcm-disable-interrupt-enable-bit-before-devm_request_irq.patch kvm-nvmx-process-events-on-nested-vm-exit-if-injectable-irq-or-nmi-is-pending.patch mptcp-always-handle-address-removal-under-msk-socket-lock.patch mptcp-reset-when-mptcp-opts-are-dropped-after-join.patch net-enetc-correct-the-xdp_tx-statistics.patch net-enetc-fix-the-off-by-one-issue-in-enetc_map_tx_buffs.patch net-enetc-fix-the-off-by-one-issue-in-enetc_map_tx_tso_buffs.patch net-enetc-keep-track-of-correct-tx-bd-count-in-enetc_map_tx_tso_buffs.patch net-enetc-update-udp-checksum-when-updating-origintimestamp-field.patch perf-core-add-rcu-read-lock-protection-to-perf_iterate_ctx.patch perf-core-fix-low-freq-setting-via-ioc_period.patch perf-x86-fix-low-freqency-setting-issue.patch phy-exynos5-usbdrd-fix-mpll_multiplier-and-ssc_refclksel-masks-in-refclk.patch phy-tegra-xusb-reset-vbus-id-override.patch rcuref-plug-slowpath-race-in-rcuref_put.patch riscv-futex-sign-extend-compare-value-in-atomic-cmpxchg.patch riscv-signal-fix-signal-frame-size.patch rseq-selftests-fix-riscv-rseq_offset_deref_addv-inline-asm.patch sched-core-prevent-rescheduling-when-interrupts-are-disabled.patch scsi-ufs-core-bsg-fix-crash-when-arpmb-command-fails.patch tracing-fix-bad-hist-from-corrupting-named_triggers-list.patch usbnet-gl620a-fix-endpoint-checking-in-genelink_bind.patch vmlinux.lds-ensure-that-const-vars-with-relocations-are-mapped-r-o.patch --- diff --git a/queue-6.6/alsa-hda-realtek-fix-microphone-regression-on-asus-n705ud.patch b/queue-6.6/alsa-hda-realtek-fix-microphone-regression-on-asus-n705ud.patch new file mode 100644 index 0000000000..a888693499 --- /dev/null +++ b/queue-6.6/alsa-hda-realtek-fix-microphone-regression-on-asus-n705ud.patch @@ -0,0 +1,81 @@ +From c6557ccf8094ce2e1142c6e49cd47f5d5e2933a8 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Adrien=20Verg=C3=A9?= +Date: Wed, 26 Feb 2025 14:55:15 +0100 +Subject: ALSA: hda/realtek: Fix microphone regression on ASUS N705UD +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Adrien Vergé + +commit c6557ccf8094ce2e1142c6e49cd47f5d5e2933a8 upstream. + +This fixes a regression introduced a few weeks ago in stable kernels +6.12.14 and 6.13.3. The internal microphone on ASUS Vivobook N705UD / +X705UD laptops is broken: the microphone appears in userspace (e.g. +Gnome settings) but no sound is detected. +I bisected it to commit 3b4309546b48 ("ALSA: hda: Fix headset detection +failure due to unstable sort"). + +I figured out the cause: +1. The initial pins enabled for the ALC256 driver are: + cfg->inputs == { + { pin=0x19, type=AUTO_PIN_MIC, + is_headset_mic=1, is_headphone_mic=0, has_boost_on_pin=1 }, + { pin=0x1a, type=AUTO_PIN_MIC, + is_headset_mic=0, is_headphone_mic=0, has_boost_on_pin=1 } } +2. Since 2017 and commits c1732ede5e8 ("ALSA: hda/realtek - Fix headset + and mic on several ASUS laptops with ALC256") and 28e8af8a163 ("ALSA: + hda/realtek: Fix mic and headset jack sense on ASUS X705UD"), the + quirk ALC256_FIXUP_ASUS_MIC is also applied to ASUS X705UD / N705UD + laptops. + This added another internal microphone on pin 0x13: + cfg->inputs == { + { pin=0x13, type=AUTO_PIN_MIC, + is_headset_mic=0, is_headphone_mic=0, has_boost_on_pin=1 }, + { pin=0x19, type=AUTO_PIN_MIC, + is_headset_mic=1, is_headphone_mic=0, has_boost_on_pin=1 }, + { pin=0x1a, type=AUTO_PIN_MIC, + is_headset_mic=0, is_headphone_mic=0, has_boost_on_pin=1 } } + I don't know what this pin 0x13 corresponds to. To the best of my + knowledge, these laptops have only one internal microphone. +3. Before 2025 and commit 3b4309546b48 ("ALSA: hda: Fix headset + detection failure due to unstable sort"), the sort function would let + the microphone of pin 0x1a (the working one) *before* the microphone + of pin 0x13 (the phantom one). +4. After this commit 3b4309546b48, the fixed sort function puts the + working microphone (pin 0x1a) *after* the phantom one (pin 0x13). As + a result, no sound is detected anymore. + +It looks like the quirk ALC256_FIXUP_ASUS_MIC is not needed anymore for +ASUS Vivobook X705UD / N705UD laptops. Without it, everything works +fine: +- the internal microphone is detected and records actual sound, +- plugging in a jack headset is detected and can record actual sound + with it, +- unplugging the jack headset makes the system go back to internal + microphone and can record actual sound. + +Cc: stable@vger.kernel.org +Cc: Kuan-Wei Chiu +Cc: Chris Chiu +Fixes: 3b4309546b48 ("ALSA: hda: Fix headset detection failure due to unstable sort") +Tested-by: Adrien Vergé +Signed-off-by: Adrien Vergé +Link: https://patch.msgid.link/20250226135515.24219-1-adrienverge@gmail.com +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + sound/pci/hda/patch_realtek.c | 1 - + 1 file changed, 1 deletion(-) + +--- a/sound/pci/hda/patch_realtek.c ++++ b/sound/pci/hda/patch_realtek.c +@@ -10115,7 +10115,6 @@ static const struct hda_quirk alc269_fix + SND_PCI_QUIRK(0x1043, 0x19ce, "ASUS B9450FA", ALC294_FIXUP_ASUS_HPE), + SND_PCI_QUIRK(0x1043, 0x19e1, "ASUS UX581LV", ALC295_FIXUP_ASUS_MIC_NO_PRESENCE), + SND_PCI_QUIRK(0x1043, 0x1a13, "Asus G73Jw", ALC269_FIXUP_ASUS_G73JW), +- SND_PCI_QUIRK(0x1043, 0x1a30, "ASUS X705UD", ALC256_FIXUP_ASUS_MIC), + SND_PCI_QUIRK(0x1043, 0x1a63, "ASUS UX3405MA", ALC245_FIXUP_CS35L41_SPI_2), + SND_PCI_QUIRK(0x1043, 0x1a83, "ASUS UM5302LA", ALC294_FIXUP_CS35L41_I2C_2), + SND_PCI_QUIRK(0x1043, 0x1a8f, "ASUS UX582ZS", ALC245_FIXUP_CS35L41_SPI_2), diff --git a/queue-6.6/alsa-usb-audio-re-add-sample-rate-quirk-for-pioneer-djm-900nxs2.patch b/queue-6.6/alsa-usb-audio-re-add-sample-rate-quirk-for-pioneer-djm-900nxs2.patch new file mode 100644 index 0000000000..ba902fb5f4 --- /dev/null +++ b/queue-6.6/alsa-usb-audio-re-add-sample-rate-quirk-for-pioneer-djm-900nxs2.patch @@ -0,0 +1,31 @@ +From 9af3b4f2d879da01192d6168e6c651e7fb5b652d Mon Sep 17 00:00:00 2001 +From: Dmitry Panchenko +Date: Thu, 20 Feb 2025 18:15:37 +0200 +Subject: ALSA: usb-audio: Re-add sample rate quirk for Pioneer DJM-900NXS2 + +From: Dmitry Panchenko + +commit 9af3b4f2d879da01192d6168e6c651e7fb5b652d upstream. + +Re-add the sample-rate quirk for the Pioneer DJM-900NXS2. This +device does not work without setting sample-rate. + +Signed-off-by: Dmitry Panchenko +Cc: +Link: https://patch.msgid.link/20250220161540.3624660-1-dmitry@d-systems.ee +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + sound/usb/quirks.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/sound/usb/quirks.c ++++ b/sound/usb/quirks.c +@@ -1775,6 +1775,7 @@ void snd_usb_set_format_quirk(struct snd + case USB_ID(0x534d, 0x2109): /* MacroSilicon MS2109 */ + subs->stream_offset_adj = 2; + break; ++ case USB_ID(0x2b73, 0x000a): /* Pioneer DJM-900NXS2 */ + case USB_ID(0x2b73, 0x0013): /* Pioneer DJM-450 */ + pioneer_djm_set_format_quirk(subs, 0x0082); + break; diff --git a/queue-6.6/drm-amd-display-disable-psr-su-on-edp-panels.patch b/queue-6.6/drm-amd-display-disable-psr-su-on-edp-panels.patch new file mode 100644 index 0000000000..79705746b5 --- /dev/null +++ b/queue-6.6/drm-amd-display-disable-psr-su-on-edp-panels.patch @@ -0,0 +1,43 @@ +From e8863f8b0316d8ee1e7e5291e8f2f72c91ac967d Mon Sep 17 00:00:00 2001 +From: Tom Chung +Date: Thu, 6 Feb 2025 11:31:23 +0800 +Subject: drm/amd/display: Disable PSR-SU on eDP panels + +From: Tom Chung + +commit e8863f8b0316d8ee1e7e5291e8f2f72c91ac967d upstream. + +[Why] +PSR-SU may cause some glitching randomly on several panels. + +[How] +Temporarily disable the PSR-SU and fallback to PSR1 for +all eDP panels. + +Link: https://gitlab.freedesktop.org/drm/amd/-/issues/3388 +Cc: Mario Limonciello +Cc: Alex Deucher +Reviewed-by: Sun peng Li +Signed-off-by: Tom Chung +Signed-off-by: Roman Li +Tested-by: Daniel Wheeler +Signed-off-by: Alex Deucher +(cherry picked from commit 6deeefb820d0efb0b36753622fb982d03b37b3ad) +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c ++++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_psr.c +@@ -51,7 +51,8 @@ static bool link_supports_psrsu(struct d + !link->dpcd_caps.psr_info.psr2_su_y_granularity_cap) + return false; + +- return dc_dmub_check_min_version(dc->ctx->dmub_srv->dmub); ++ /* Temporarily disable PSR-SU to avoid glitches */ ++ return false; + } + + /* diff --git a/queue-6.6/drm-amd-display-fix-hpd-after-gpu-reset.patch b/queue-6.6/drm-amd-display-fix-hpd-after-gpu-reset.patch new file mode 100644 index 0000000000..1dea92a30f --- /dev/null +++ b/queue-6.6/drm-amd-display-fix-hpd-after-gpu-reset.patch @@ -0,0 +1,74 @@ +From 4de141b8b1b7991b607f77e5f4580e1c67c24717 Mon Sep 17 00:00:00 2001 +From: Roman Li +Date: Wed, 12 Feb 2025 14:49:36 -0500 +Subject: drm/amd/display: Fix HPD after gpu reset + +From: Roman Li + +commit 4de141b8b1b7991b607f77e5f4580e1c67c24717 upstream. + +[Why] +DC is not using amdgpu_irq_get/put to manage the HPD interrupt refcounts. +So when amdgpu_irq_gpu_reset_resume_helper() reprograms all of the IRQs, +HPD gets disabled. + +[How] +Use amdgpu_irq_get/put() for HPD init/fini in DM in order to sync refcounts + +Cc: Mario Limonciello +Cc: Alex Deucher +Reviewed-by: Mario Limonciello +Reviewed-by: Aurabindo Pillai +Signed-off-by: Roman Li +Signed-off-by: Zaeem Mohamed +Tested-by: Daniel Wheeler +Signed-off-by: Alex Deucher +(cherry picked from commit f3dde2ff7fcaacd77884502e8f572f2328e9c745) +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c | 14 ++++++++++++++ + 1 file changed, 14 insertions(+) + +--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c ++++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c +@@ -891,6 +891,7 @@ void amdgpu_dm_hpd_init(struct amdgpu_de + struct drm_device *dev = adev_to_drm(adev); + struct drm_connector *connector; + struct drm_connector_list_iter iter; ++ int i; + + drm_connector_list_iter_begin(dev, &iter); + drm_for_each_connector_iter(connector, &iter) { +@@ -912,6 +913,12 @@ void amdgpu_dm_hpd_init(struct amdgpu_de + } + } + drm_connector_list_iter_end(&iter); ++ ++ /* Update reference counts for HPDs */ ++ for (i = DC_IRQ_SOURCE_HPD1; i <= adev->mode_info.num_hpd; i++) { ++ if (amdgpu_irq_get(adev, &adev->hpd_irq, i - DC_IRQ_SOURCE_HPD1)) ++ drm_err(dev, "DM_IRQ: Failed get HPD for source=%d)!\n", i); ++ } + } + + /** +@@ -927,6 +934,7 @@ void amdgpu_dm_hpd_fini(struct amdgpu_de + struct drm_device *dev = adev_to_drm(adev); + struct drm_connector *connector; + struct drm_connector_list_iter iter; ++ int i; + + drm_connector_list_iter_begin(dev, &iter); + drm_for_each_connector_iter(connector, &iter) { +@@ -947,4 +955,10 @@ void amdgpu_dm_hpd_fini(struct amdgpu_de + } + } + drm_connector_list_iter_end(&iter); ++ ++ /* Update reference counts for HPDs */ ++ for (i = DC_IRQ_SOURCE_HPD1; i <= adev->mode_info.num_hpd; i++) { ++ if (amdgpu_irq_put(adev, &adev->hpd_irq, i - DC_IRQ_SOURCE_HPD1)) ++ drm_err(dev, "DM_IRQ: Failed put HPD for source=%d!\n", i); ++ } + } diff --git a/queue-6.6/ftrace-avoid-potential-division-by-zero-in-function_stat_show.patch b/queue-6.6/ftrace-avoid-potential-division-by-zero-in-function_stat_show.patch new file mode 100644 index 0000000000..ccf7612f95 --- /dev/null +++ b/queue-6.6/ftrace-avoid-potential-division-by-zero-in-function_stat_show.patch @@ -0,0 +1,73 @@ +From a1a7eb89ca0b89dc1c326eeee2596f263291aca3 Mon Sep 17 00:00:00 2001 +From: Nikolay Kuratov +Date: Thu, 6 Feb 2025 12:01:56 +0300 +Subject: ftrace: Avoid potential division by zero in function_stat_show() + +From: Nikolay Kuratov + +commit a1a7eb89ca0b89dc1c326eeee2596f263291aca3 upstream. + +Check whether denominator expression x * (x - 1) * 1000 mod {2^32, 2^64} +produce zero and skip stddev computation in that case. + +For now don't care about rec->counter * rec->counter overflow because +rec->time * rec->time overflow will likely happen earlier. + +Cc: stable@vger.kernel.org +Cc: Wen Yang +Cc: Mark Rutland +Cc: Mathieu Desnoyers +Link: https://lore.kernel.org/20250206090156.1561783-1-kniv@yandex-team.ru +Fixes: e31f7939c1c27 ("ftrace: Avoid potential division by zero in function profiler") +Signed-off-by: Nikolay Kuratov +Signed-off-by: Steven Rostedt (Google) +Signed-off-by: Greg Kroah-Hartman +--- + kernel/trace/ftrace.c | 27 ++++++++++++--------------- + 1 file changed, 12 insertions(+), 15 deletions(-) + +--- a/kernel/trace/ftrace.c ++++ b/kernel/trace/ftrace.c +@@ -538,6 +538,7 @@ static int function_stat_show(struct seq + static struct trace_seq s; + unsigned long long avg; + unsigned long long stddev; ++ unsigned long long stddev_denom; + #endif + mutex_lock(&ftrace_profile_lock); + +@@ -559,23 +560,19 @@ static int function_stat_show(struct seq + #ifdef CONFIG_FUNCTION_GRAPH_TRACER + seq_puts(m, " "); + +- /* Sample standard deviation (s^2) */ +- if (rec->counter <= 1) +- stddev = 0; +- else { +- /* +- * Apply Welford's method: +- * s^2 = 1 / (n * (n-1)) * (n * \Sum (x_i)^2 - (\Sum x_i)^2) +- */ ++ /* ++ * Variance formula: ++ * s^2 = 1 / (n * (n-1)) * (n * \Sum (x_i)^2 - (\Sum x_i)^2) ++ * Maybe Welford's method is better here? ++ * Divide only by 1000 for ns^2 -> us^2 conversion. ++ * trace_print_graph_duration will divide by 1000 again. ++ */ ++ stddev = 0; ++ stddev_denom = rec->counter * (rec->counter - 1) * 1000; ++ if (stddev_denom) { + stddev = rec->counter * rec->time_squared - + rec->time * rec->time; +- +- /* +- * Divide only 1000 for ns^2 -> us^2 conversion. +- * trace_print_graph_duration will divide 1000 again. +- */ +- stddev = div64_ul(stddev, +- rec->counter * (rec->counter - 1) * 1000); ++ stddev = div64_ul(stddev, stddev_denom); + } + + trace_seq_init(&s); diff --git a/queue-6.6/i2c-ls2x-fix-frequency-division-register-access.patch b/queue-6.6/i2c-ls2x-fix-frequency-division-register-access.patch new file mode 100644 index 0000000000..e9c91e65bf --- /dev/null +++ b/queue-6.6/i2c-ls2x-fix-frequency-division-register-access.patch @@ -0,0 +1,79 @@ +From 71c49ee9bb41e1709abac7e2eb05f9193222e580 Mon Sep 17 00:00:00 2001 +From: Binbin Zhou +Date: Thu, 20 Feb 2025 20:56:12 +0800 +Subject: i2c: ls2x: Fix frequency division register access + +From: Binbin Zhou + +commit 71c49ee9bb41e1709abac7e2eb05f9193222e580 upstream. + +According to the chip manual, the I2C register access type of +Loongson-2K2000/LS7A is "B", so we can only access registers in byte +form (readb()/writeb()). + +Although Loongson-2K0500/Loongson-2K1000 do not have similar +constraints, register accesses in byte form also behave correctly. + +Also, in hardware, the frequency division registers are defined as two +separate registers (high 8-bit and low 8-bit), so we just access them +directly as bytes. + +Fixes: 015e61f0bffd ("i2c: ls2x: Add driver for Loongson-2K/LS7A I2C controller") +Co-developed-by: Hongliang Wang +Signed-off-by: Hongliang Wang +Signed-off-by: Binbin Zhou +Cc: stable@vger.kernel.org # v6.3+ +Reviewed-by: Andy Shevchenko +Signed-off-by: Andi Shyti +Link: https://lore.kernel.org/r/20250220125612.1910990-1-zhoubinbin@loongson.cn +Signed-off-by: Greg Kroah-Hartman +--- + drivers/i2c/busses/i2c-ls2x.c | 16 ++++++++++++---- + 1 file changed, 12 insertions(+), 4 deletions(-) + +--- a/drivers/i2c/busses/i2c-ls2x.c ++++ b/drivers/i2c/busses/i2c-ls2x.c +@@ -10,6 +10,7 @@ + * Rewritten for mainline by Binbin Zhou + */ + ++#include + #include + #include + #include +@@ -26,7 +27,8 @@ + #include + + /* I2C Registers */ +-#define I2C_LS2X_PRER 0x0 /* Freq Division Register(16 bits) */ ++#define I2C_LS2X_PRER_LO 0x0 /* Freq Division Low Byte Register */ ++#define I2C_LS2X_PRER_HI 0x1 /* Freq Division High Byte Register */ + #define I2C_LS2X_CTR 0x2 /* Control Register */ + #define I2C_LS2X_TXR 0x3 /* Transport Data Register */ + #define I2C_LS2X_RXR 0x3 /* Receive Data Register */ +@@ -93,6 +95,7 @@ static irqreturn_t ls2x_i2c_isr(int this + */ + static void ls2x_i2c_adjust_bus_speed(struct ls2x_i2c_priv *priv) + { ++ u16 val; + struct i2c_timings *t = &priv->i2c_t; + struct device *dev = priv->adapter.dev.parent; + u32 acpi_speed = i2c_acpi_find_bus_speed(dev); +@@ -104,9 +107,14 @@ static void ls2x_i2c_adjust_bus_speed(st + else + t->bus_freq_hz = LS2X_I2C_FREQ_STD; + +- /* Calculate and set i2c frequency. */ +- writew(LS2X_I2C_PCLK_FREQ / (5 * t->bus_freq_hz) - 1, +- priv->base + I2C_LS2X_PRER); ++ /* ++ * According to the chip manual, we can only access the registers as bytes, ++ * otherwise the high bits will be truncated. ++ * So set the I2C frequency with a sequential writeb() instead of writew(). ++ */ ++ val = LS2X_I2C_PCLK_FREQ / (5 * t->bus_freq_hz) - 1; ++ writeb(FIELD_GET(GENMASK(7, 0), val), priv->base + I2C_LS2X_PRER_LO); ++ writeb(FIELD_GET(GENMASK(15, 8), val), priv->base + I2C_LS2X_PRER_HI); + } + + static void ls2x_i2c_init(struct ls2x_i2c_priv *priv) diff --git a/queue-6.6/i2c-npcm-disable-interrupt-enable-bit-before-devm_request_irq.patch b/queue-6.6/i2c-npcm-disable-interrupt-enable-bit-before-devm_request_irq.patch new file mode 100644 index 0000000000..81e95132ab --- /dev/null +++ b/queue-6.6/i2c-npcm-disable-interrupt-enable-bit-before-devm_request_irq.patch @@ -0,0 +1,104 @@ +From dd1998e243f5fa25d348a384ba0b6c84d980f2b2 Mon Sep 17 00:00:00 2001 +From: Tyrone Ting +Date: Thu, 20 Feb 2025 12:00:29 +0800 +Subject: i2c: npcm: disable interrupt enable bit before devm_request_irq + +From: Tyrone Ting + +commit dd1998e243f5fa25d348a384ba0b6c84d980f2b2 upstream. + +The customer reports that there is a soft lockup issue related to +the i2c driver. After checking, the i2c module was doing a tx transfer +and the bmc machine reboots in the middle of the i2c transaction, the i2c +module keeps the status without being reset. + +Due to such an i2c module status, the i2c irq handler keeps getting +triggered since the i2c irq handler is registered in the kernel booting +process after the bmc machine is doing a warm rebooting. +The continuous triggering is stopped by the soft lockup watchdog timer. + +Disable the interrupt enable bit in the i2c module before calling +devm_request_irq to fix this issue since the i2c relative status bit +is read-only. + +Here is the soft lockup log. +[ 28.176395] watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [swapper/0:1] +[ 28.183351] Modules linked in: +[ 28.186407] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.15.120-yocto-s-dirty-bbebc78 #1 +[ 28.201174] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) +[ 28.208128] pc : __do_softirq+0xb0/0x368 +[ 28.212055] lr : __do_softirq+0x70/0x368 +[ 28.215972] sp : ffffff8035ebca00 +[ 28.219278] x29: ffffff8035ebca00 x28: 0000000000000002 x27: ffffff80071a3780 +[ 28.226412] x26: ffffffc008bdc000 x25: ffffffc008bcc640 x24: ffffffc008be50c0 +[ 28.233546] x23: ffffffc00800200c x22: 0000000000000000 x21: 000000000000001b +[ 28.240679] x20: 0000000000000000 x19: ffffff80001c3200 x18: ffffffffffffffff +[ 28.247812] x17: ffffffc02d2e0000 x16: ffffff8035eb8b40 x15: 00001e8480000000 +[ 28.254945] x14: 02c3647e37dbfcb6 x13: 02c364f2ab14200c x12: 0000000002c364f2 +[ 28.262078] x11: 00000000fa83b2da x10: 000000000000b67e x9 : ffffffc008010250 +[ 28.269211] x8 : 000000009d983d00 x7 : 7fffffffffffffff x6 : 0000036d74732434 +[ 28.276344] x5 : 00ffffffffffffff x4 : 0000000000000015 x3 : 0000000000000198 +[ 28.283476] x2 : ffffffc02d2e0000 x1 : 00000000000000e0 x0 : ffffffc008bdcb40 +[ 28.290611] Call trace: +[ 28.293052] __do_softirq+0xb0/0x368 +[ 28.296625] __irq_exit_rcu+0xe0/0x100 +[ 28.300374] irq_exit+0x14/0x20 +[ 28.303513] handle_domain_irq+0x68/0x90 +[ 28.307440] gic_handle_irq+0x78/0xb0 +[ 28.311098] call_on_irq_stack+0x20/0x38 +[ 28.315019] do_interrupt_handler+0x54/0x5c +[ 28.319199] el1_interrupt+0x2c/0x4c +[ 28.322777] el1h_64_irq_handler+0x14/0x20 +[ 28.326872] el1h_64_irq+0x74/0x78 +[ 28.330269] __setup_irq+0x454/0x780 +[ 28.333841] request_threaded_irq+0xd0/0x1b4 +[ 28.338107] devm_request_threaded_irq+0x84/0x100 +[ 28.342809] npcm_i2c_probe_bus+0x188/0x3d0 +[ 28.346990] platform_probe+0x6c/0xc4 +[ 28.350653] really_probe+0xcc/0x45c +[ 28.354227] __driver_probe_device+0x8c/0x160 +[ 28.358578] driver_probe_device+0x44/0xe0 +[ 28.362670] __driver_attach+0x124/0x1d0 +[ 28.366589] bus_for_each_dev+0x7c/0xe0 +[ 28.370426] driver_attach+0x28/0x30 +[ 28.373997] bus_add_driver+0x124/0x240 +[ 28.377830] driver_register+0x7c/0x124 +[ 28.381662] __platform_driver_register+0x2c/0x34 +[ 28.386362] npcm_i2c_init+0x3c/0x5c +[ 28.389937] do_one_initcall+0x74/0x230 +[ 28.393768] kernel_init_freeable+0x24c/0x2b4 +[ 28.398126] kernel_init+0x28/0x130 +[ 28.401614] ret_from_fork+0x10/0x20 +[ 28.405189] Kernel panic - not syncing: softlockup: hung tasks +[ 28.411011] SMP: stopping secondary CPUs +[ 28.414933] Kernel Offset: disabled +[ 28.418412] CPU features: 0x00000000,00000802 +[ 28.427644] Rebooting in 20 seconds.. + +Fixes: 56a1485b102e ("i2c: npcm7xx: Add Nuvoton NPCM I2C controller driver") +Signed-off-by: Tyrone Ting +Cc: # v5.8+ +Reviewed-by: Tali Perry +Signed-off-by: Andi Shyti +Link: https://lore.kernel.org/r/20250220040029.27596-2-kfting@nuvoton.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/i2c/busses/i2c-npcm7xx.c | 7 +++++++ + 1 file changed, 7 insertions(+) + +--- a/drivers/i2c/busses/i2c-npcm7xx.c ++++ b/drivers/i2c/busses/i2c-npcm7xx.c +@@ -2333,6 +2333,13 @@ static int npcm_i2c_probe_bus(struct pla + if (irq < 0) + return irq; + ++ /* ++ * Disable the interrupt to avoid the interrupt handler being triggered ++ * incorrectly by the asynchronous interrupt status since the machine ++ * might do a warm reset during the last smbus/i2c transfer session. ++ */ ++ npcm_i2c_int_enable(bus, false); ++ + ret = devm_request_irq(bus->dev, irq, npcm_i2c_bus_irq, 0, + dev_name(bus->dev), bus); + if (ret) diff --git a/queue-6.6/kvm-nvmx-process-events-on-nested-vm-exit-if-injectable-irq-or-nmi-is-pending.patch b/queue-6.6/kvm-nvmx-process-events-on-nested-vm-exit-if-injectable-irq-or-nmi-is-pending.patch new file mode 100644 index 0000000000..fba71087e7 --- /dev/null +++ b/queue-6.6/kvm-nvmx-process-events-on-nested-vm-exit-if-injectable-irq-or-nmi-is-pending.patch @@ -0,0 +1,50 @@ +From 982caaa1150479f022003390cd72a1941663d211 Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +Date: Mon, 24 Feb 2025 15:55:37 -0800 +Subject: KVM: nVMX: Process events on nested VM-Exit if injectable IRQ or NMI is pending + +From: Sean Christopherson + +commit 982caaa1150479f022003390cd72a1941663d211 upstream. + +Process pending events on nested VM-Exit if the vCPU has an injectable IRQ +or NMI, as the event may have become pending while L2 was active, i.e. may +not be tracked in the context of vmcs01. E.g. if L1 has passed its APIC +through to L2 and an IRQ arrives while L2 is active, then KVM needs to +request an IRQ window prior to running L1, otherwise delivery of the IRQ +will be delayed until KVM happens to process events for some other reason. + +The missed failure is detected by vmx_apic_passthrough_tpr_threshold_test +in KVM-Unit-Tests, but has effectively been masked due to a flaw in KVM's +PIC emulation that causes KVM to make spurious KVM_REQ_EVENT requests (and +apparently no one ever ran the test with split IRQ chips). + +Cc: stable@vger.kernel.org +Signed-off-by: Sean Christopherson +Message-ID: <20250224235542.2562848-3-seanjc@google.com> +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kvm/vmx/nested.c | 11 +++++++++++ + 1 file changed, 11 insertions(+) + +--- a/arch/x86/kvm/vmx/nested.c ++++ b/arch/x86/kvm/vmx/nested.c +@@ -4926,6 +4926,17 @@ void nested_vmx_vmexit(struct kvm_vcpu * + + load_vmcs12_host_state(vcpu, vmcs12); + ++ /* ++ * Process events if an injectable IRQ or NMI is pending, even ++ * if the event is blocked (RFLAGS.IF is cleared on VM-Exit). ++ * If an event became pending while L2 was active, KVM needs to ++ * either inject the event or request an IRQ/NMI window. SMIs ++ * don't need to be processed as SMM is mutually exclusive with ++ * non-root mode. INIT/SIPI don't need to be checked as INIT ++ * is blocked post-VMXON, and SIPIs are ignored. ++ */ ++ if (kvm_cpu_has_injectable_intr(vcpu) || vcpu->arch.nmi_pending) ++ kvm_make_request(KVM_REQ_EVENT, vcpu); + return; + } + diff --git a/queue-6.6/mptcp-always-handle-address-removal-under-msk-socket-lock.patch b/queue-6.6/mptcp-always-handle-address-removal-under-msk-socket-lock.patch new file mode 100644 index 0000000000..b2da5b3ba0 --- /dev/null +++ b/queue-6.6/mptcp-always-handle-address-removal-under-msk-socket-lock.patch @@ -0,0 +1,108 @@ +From f865c24bc55158313d5779fc81116023a6940ca3 Mon Sep 17 00:00:00 2001 +From: Paolo Abeni +Date: Mon, 24 Feb 2025 19:11:50 +0100 +Subject: mptcp: always handle address removal under msk socket lock + +From: Paolo Abeni + +commit f865c24bc55158313d5779fc81116023a6940ca3 upstream. + +Syzkaller reported a lockdep splat in the PM control path: + + WARNING: CPU: 0 PID: 6693 at ./include/net/sock.h:1711 sock_owned_by_me include/net/sock.h:1711 [inline] + WARNING: CPU: 0 PID: 6693 at ./include/net/sock.h:1711 msk_owned_by_me net/mptcp/protocol.h:363 [inline] + WARNING: CPU: 0 PID: 6693 at ./include/net/sock.h:1711 mptcp_pm_nl_addr_send_ack+0x57c/0x610 net/mptcp/pm_netlink.c:788 + Modules linked in: + CPU: 0 UID: 0 PID: 6693 Comm: syz.0.205 Not tainted 6.14.0-rc2-syzkaller-00303-gad1b832bf1cf #0 + Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 12/27/2024 + RIP: 0010:sock_owned_by_me include/net/sock.h:1711 [inline] + RIP: 0010:msk_owned_by_me net/mptcp/protocol.h:363 [inline] + RIP: 0010:mptcp_pm_nl_addr_send_ack+0x57c/0x610 net/mptcp/pm_netlink.c:788 + Code: 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 ca 7b d3 f5 eb b9 e8 c3 7b d3 f5 90 0f 0b 90 e9 dd fb ff ff e8 b5 7b d3 f5 90 <0f> 0b 90 e9 3e fb ff ff 44 89 f1 80 e1 07 38 c1 0f 8c eb fb ff ff + RSP: 0000:ffffc900034f6f60 EFLAGS: 00010283 + RAX: ffffffff8bee3c2b RBX: 0000000000000001 RCX: 0000000000080000 + RDX: ffffc90004d42000 RSI: 000000000000a407 RDI: 000000000000a408 + RBP: ffffc900034f7030 R08: ffffffff8bee37f6 R09: 0100000000000000 + R10: dffffc0000000000 R11: ffffed100bcc62e4 R12: ffff88805e6316e0 + R13: ffff88805e630c00 R14: dffffc0000000000 R15: ffff88805e630c00 + FS: 00007f7e9a7e96c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 + CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 + CR2: 0000001b2fd18ff8 CR3: 0000000032c24000 CR4: 00000000003526f0 + DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 + DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 + Call Trace: + + mptcp_pm_remove_addr+0x103/0x1d0 net/mptcp/pm.c:59 + mptcp_pm_remove_anno_addr+0x1f4/0x2f0 net/mptcp/pm_netlink.c:1486 + mptcp_nl_remove_subflow_and_signal_addr net/mptcp/pm_netlink.c:1518 [inline] + mptcp_pm_nl_del_addr_doit+0x118d/0x1af0 net/mptcp/pm_netlink.c:1629 + genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline] + genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] + genl_rcv_msg+0xb1f/0xec0 net/netlink/genetlink.c:1210 + netlink_rcv_skb+0x206/0x480 net/netlink/af_netlink.c:2543 + genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 + netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline] + netlink_unicast+0x7f6/0x990 net/netlink/af_netlink.c:1348 + netlink_sendmsg+0x8de/0xcb0 net/netlink/af_netlink.c:1892 + sock_sendmsg_nosec net/socket.c:718 [inline] + __sock_sendmsg+0x221/0x270 net/socket.c:733 + ____sys_sendmsg+0x53a/0x860 net/socket.c:2573 + ___sys_sendmsg net/socket.c:2627 [inline] + __sys_sendmsg+0x269/0x350 net/socket.c:2659 + do_syscall_x64 arch/x86/entry/common.c:52 [inline] + do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 + entry_SYSCALL_64_after_hwframe+0x77/0x7f + RIP: 0033:0x7f7e9998cde9 + Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 + RSP: 002b:00007f7e9a7e9038 EFLAGS: 00000246 ORIG_RAX: 000000000000002e + RAX: ffffffffffffffda RBX: 00007f7e99ba5fa0 RCX: 00007f7e9998cde9 + RDX: 000000002000c094 RSI: 0000400000000000 RDI: 0000000000000007 + RBP: 00007f7e99a0e2a0 R08: 0000000000000000 R09: 0000000000000000 + R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 + R13: 0000000000000000 R14: 00007f7e99ba5fa0 R15: 00007fff49231088 + +Indeed the PM can try to send a RM_ADDR over a msk without acquiring +first the msk socket lock. + +The bugged code-path comes from an early optimization: when there +are no subflows, the PM should (usually) not send RM_ADDR +notifications. + +The above statement is incorrect, as without locks another process +could concurrent create a new subflow and cause the RM_ADDR generation. + +Additionally the supposed optimization is not very effective even +performance-wise, as most mptcp sockets should have at least one +subflow: the MPC one. + +Address the issue removing the buggy code path, the existing "slow-path" +will handle correctly even the edge case. + +Fixes: b6c08380860b ("mptcp: remove addr and subflow in PM netlink") +Cc: stable@vger.kernel.org +Reported-by: syzbot+cd3ce3d03a3393ae9700@syzkaller.appspotmail.com +Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/546 +Signed-off-by: Paolo Abeni +Reviewed-by: Matthieu Baerts (NGI0) +Signed-off-by: Matthieu Baerts (NGI0) +Link: https://patch.msgid.link/20250224-net-mptcp-misc-fixes-v1-1-f550f636b435@kernel.org +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + net/mptcp/pm_netlink.c | 5 ----- + 1 file changed, 5 deletions(-) + +--- a/net/mptcp/pm_netlink.c ++++ b/net/mptcp/pm_netlink.c +@@ -1559,11 +1559,6 @@ static int mptcp_nl_remove_subflow_and_s + if (mptcp_pm_is_userspace(msk)) + goto next; + +- if (list_empty(&msk->conn_list)) { +- mptcp_pm_remove_anno_addr(msk, addr, false); +- goto next; +- } +- + lock_sock(sk); + remove_subflow = lookup_subflow_by_saddr(&msk->conn_list, addr); + mptcp_pm_remove_anno_addr(msk, addr, remove_subflow && diff --git a/queue-6.6/mptcp-reset-when-mptcp-opts-are-dropped-after-join.patch b/queue-6.6/mptcp-reset-when-mptcp-opts-are-dropped-after-join.patch new file mode 100644 index 0000000000..09a929e459 --- /dev/null +++ b/queue-6.6/mptcp-reset-when-mptcp-opts-are-dropped-after-join.patch @@ -0,0 +1,91 @@ +From 8668860b0ad32a13fcd6c94a0995b7aa7638c9ef Mon Sep 17 00:00:00 2001 +From: "Matthieu Baerts (NGI0)" +Date: Mon, 24 Feb 2025 19:11:51 +0100 +Subject: mptcp: reset when MPTCP opts are dropped after join + +From: Matthieu Baerts (NGI0) + +commit 8668860b0ad32a13fcd6c94a0995b7aa7638c9ef upstream. + +Before this patch, if the checksum was not used, the subflow was only +reset if map_data_len was != 0. If there were no MPTCP options or an +invalid mapping, map_data_len was not set to the data len, and then the +subflow was not reset as it should have been, leaving the MPTCP +connection in a wrong fallback mode. + +This map_data_len condition has been introduced to handle the reception +of the infinite mapping. Instead, a new dedicated mapping error could +have been returned and treated as a special case. However, the commit +31bf11de146c ("mptcp: introduce MAPPING_BAD_CSUM") has been introduced +by Paolo Abeni soon after, and backported later on to stable. It better +handle the csum case, and it means the exception for valid_csum_seen in +subflow_can_fallback(), plus this one for the infinite mapping in +subflow_check_data_avail(), are no longer needed. + +In other words, the code can be simplified there: a fallback should only +be done if msk->allow_infinite_fallback is set. This boolean is set to +false once MPTCP-specific operations acting on the whole MPTCP +connection vs the initial path have been done, e.g. a second path has +been created, or an MPTCP re-injection -- yes, possible even with a +single subflow. The subflow_can_fallback() helper can then be dropped, +and replaced by this single condition. + +This also makes the code clearer: a fallback should only be done if it +is possible to do so. + +While at it, no need to set map_data_len to 0 in get_mapping_status() +for the infinite mapping case: it will be set to skb->len just after, at +the end of subflow_check_data_avail(), and not read in between. + +Fixes: f8d4bcacff3b ("mptcp: infinite mapping receiving") +Cc: stable@vger.kernel.org +Reported-by: Chester A. Unal +Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/544 +Acked-by: Paolo Abeni +Signed-off-by: Matthieu Baerts (NGI0) +Tested-by: Chester A. Unal +Link: https://patch.msgid.link/20250224-net-mptcp-misc-fixes-v1-2-f550f636b435@kernel.org +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + net/mptcp/subflow.c | 15 +-------------- + 1 file changed, 1 insertion(+), 14 deletions(-) + +--- a/net/mptcp/subflow.c ++++ b/net/mptcp/subflow.c +@@ -1109,7 +1109,6 @@ static enum mapping_status get_mapping_s + if (data_len == 0) { + pr_debug("infinite mapping received\n"); + MPTCP_INC_STATS(sock_net(ssk), MPTCP_MIB_INFINITEMAPRX); +- subflow->map_data_len = 0; + return MAPPING_INVALID; + } + +@@ -1251,18 +1250,6 @@ static void subflow_sched_work_if_closed + mptcp_schedule_work(sk); + } + +-static bool subflow_can_fallback(struct mptcp_subflow_context *subflow) +-{ +- struct mptcp_sock *msk = mptcp_sk(subflow->conn); +- +- if (subflow->mp_join) +- return false; +- else if (READ_ONCE(msk->csum_enabled)) +- return !subflow->valid_csum_seen; +- else +- return READ_ONCE(msk->allow_infinite_fallback); +-} +- + static void mptcp_subflow_fail(struct mptcp_sock *msk, struct sock *ssk) + { + struct mptcp_subflow_context *subflow = mptcp_subflow_ctx(ssk); +@@ -1358,7 +1345,7 @@ fallback: + return true; + } + +- if (!subflow_can_fallback(subflow) && subflow->map_data_len) { ++ if (!READ_ONCE(msk->allow_infinite_fallback)) { + /* fatal protocol error, close the socket. + * subflow_error_report() will introduce the appropriate barriers + */ diff --git a/queue-6.6/net-enetc-correct-the-xdp_tx-statistics.patch b/queue-6.6/net-enetc-correct-the-xdp_tx-statistics.patch new file mode 100644 index 0000000000..630fd97eaa --- /dev/null +++ b/queue-6.6/net-enetc-correct-the-xdp_tx-statistics.patch @@ -0,0 +1,35 @@ +From 432a2cb3ee97a7c6ea578888fe81baad035b9307 Mon Sep 17 00:00:00 2001 +From: Wei Fang +Date: Mon, 24 Feb 2025 19:12:46 +0800 +Subject: net: enetc: correct the xdp_tx statistics + +From: Wei Fang + +commit 432a2cb3ee97a7c6ea578888fe81baad035b9307 upstream. + +The 'xdp_tx' is used to count the number of XDP_TX frames sent, not the +number of Tx BDs. + +Fixes: 7ed2bc80074e ("net: enetc: add support for XDP_TX") +Cc: stable@vger.kernel.org +Signed-off-by: Wei Fang +Reviewed-by: Ioana Ciornei +Reviewed-by: Vladimir Oltean +Link: https://patch.msgid.link/20250224111251.1061098-4-wei.fang@nxp.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/freescale/enetc/enetc.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/net/ethernet/freescale/enetc/enetc.c ++++ b/drivers/net/ethernet/freescale/enetc/enetc.c +@@ -1669,7 +1669,7 @@ static int enetc_clean_rx_ring_xdp(struc + enetc_xdp_drop(rx_ring, orig_i, i); + tx_ring->stats.xdp_tx_drops++; + } else { +- tx_ring->stats.xdp_tx += xdp_tx_bd_cnt; ++ tx_ring->stats.xdp_tx++; + rx_ring->xdp.xdp_tx_in_flight += xdp_tx_bd_cnt; + xdp_tx_frm_cnt++; + /* The XDP_TX enqueue was successful, so we diff --git a/queue-6.6/net-enetc-fix-the-off-by-one-issue-in-enetc_map_tx_buffs.patch b/queue-6.6/net-enetc-fix-the-off-by-one-issue-in-enetc_map_tx_buffs.patch new file mode 100644 index 0000000000..91e84c49ec --- /dev/null +++ b/queue-6.6/net-enetc-fix-the-off-by-one-issue-in-enetc_map_tx_buffs.patch @@ -0,0 +1,68 @@ +From 39ab773e4c120f7f98d759415ccc2aca706bbc10 Mon Sep 17 00:00:00 2001 +From: Wei Fang +Date: Mon, 24 Feb 2025 19:12:44 +0800 +Subject: net: enetc: fix the off-by-one issue in enetc_map_tx_buffs() + +From: Wei Fang + +commit 39ab773e4c120f7f98d759415ccc2aca706bbc10 upstream. + +When a DMA mapping error occurs while processing skb frags, it will free +one more tx_swbd than expected, so fix this off-by-one issue. + +Fixes: d4fd0404c1c9 ("enetc: Introduce basic PF and VF ENETC ethernet drivers") +Cc: stable@vger.kernel.org +Suggested-by: Vladimir Oltean +Suggested-by: Michal Swiatkowski +Signed-off-by: Wei Fang +Reviewed-by: Vladimir Oltean +Reviewed-by: Claudiu Manoil +Link: https://patch.msgid.link/20250224111251.1061098-2-wei.fang@nxp.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/freescale/enetc/enetc.c | 26 +++++++++++++++++++------- + 1 file changed, 19 insertions(+), 7 deletions(-) + +--- a/drivers/net/ethernet/freescale/enetc/enetc.c ++++ b/drivers/net/ethernet/freescale/enetc/enetc.c +@@ -145,6 +145,24 @@ static int enetc_ptp_parse(struct sk_buf + return 0; + } + ++/** ++ * enetc_unwind_tx_frame() - Unwind the DMA mappings of a multi-buffer Tx frame ++ * @tx_ring: Pointer to the Tx ring on which the buffer descriptors are located ++ * @count: Number of Tx buffer descriptors which need to be unmapped ++ * @i: Index of the last successfully mapped Tx buffer descriptor ++ */ ++static void enetc_unwind_tx_frame(struct enetc_bdr *tx_ring, int count, int i) ++{ ++ while (count--) { ++ struct enetc_tx_swbd *tx_swbd = &tx_ring->tx_swbd[i]; ++ ++ enetc_free_tx_frame(tx_ring, tx_swbd); ++ if (i == 0) ++ i = tx_ring->bd_count; ++ i--; ++ } ++} ++ + static int enetc_map_tx_buffs(struct enetc_bdr *tx_ring, struct sk_buff *skb) + { + bool do_vlan, do_onestep_tstamp = false, do_twostep_tstamp = false; +@@ -328,13 +346,7 @@ static int enetc_map_tx_buffs(struct ene + dma_err: + dev_err(tx_ring->dev, "DMA map error"); + +- do { +- tx_swbd = &tx_ring->tx_swbd[i]; +- enetc_free_tx_frame(tx_ring, tx_swbd); +- if (i == 0) +- i = tx_ring->bd_count; +- i--; +- } while (count--); ++ enetc_unwind_tx_frame(tx_ring, count, i); + + return 0; + } diff --git a/queue-6.6/net-enetc-fix-the-off-by-one-issue-in-enetc_map_tx_tso_buffs.patch b/queue-6.6/net-enetc-fix-the-off-by-one-issue-in-enetc_map_tx_tso_buffs.patch new file mode 100644 index 0000000000..fe1c227ff1 --- /dev/null +++ b/queue-6.6/net-enetc-fix-the-off-by-one-issue-in-enetc_map_tx_tso_buffs.patch @@ -0,0 +1,60 @@ +From 249df695c3ffe8c8d36d46c2580ce72410976f96 Mon Sep 17 00:00:00 2001 +From: Wei Fang +Date: Mon, 24 Feb 2025 19:12:51 +0800 +Subject: net: enetc: fix the off-by-one issue in enetc_map_tx_tso_buffs() + +From: Wei Fang + +commit 249df695c3ffe8c8d36d46c2580ce72410976f96 upstream. + +There is an off-by-one issue for the err_chained_bd path, it will free +one more tx_swbd than expected. But there is no such issue for the +err_map_data path. To fix this off-by-one issue and make the two error +handling consistent, the increment of 'i' and 'count' remain in sync +and enetc_unwind_tx_frame() is called for error handling. + +Fixes: fb8629e2cbfc ("net: enetc: add support for software TSO") +Cc: stable@vger.kernel.org +Suggested-by: Vladimir Oltean +Signed-off-by: Wei Fang +Reviewed-by: Vladimir Oltean +Reviewed-by: Claudiu Manoil +Link: https://patch.msgid.link/20250224111251.1061098-9-wei.fang@nxp.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/freescale/enetc/enetc.c | 15 +++++++-------- + 1 file changed, 7 insertions(+), 8 deletions(-) + +--- a/drivers/net/ethernet/freescale/enetc/enetc.c ++++ b/drivers/net/ethernet/freescale/enetc/enetc.c +@@ -590,8 +590,13 @@ static int enetc_map_tx_tso_buffs(struct + err = enetc_map_tx_tso_data(tx_ring, skb, tx_swbd, txbd, + tso.data, size, + size == data_len); +- if (err) ++ if (err) { ++ if (i == 0) ++ i = tx_ring->bd_count; ++ i--; ++ + goto err_map_data; ++ } + + data_len -= size; + count++; +@@ -620,13 +625,7 @@ err_map_data: + dev_err(tx_ring->dev, "DMA map error"); + + err_chained_bd: +- do { +- tx_swbd = &tx_ring->tx_swbd[i]; +- enetc_free_tx_frame(tx_ring, tx_swbd); +- if (i == 0) +- i = tx_ring->bd_count; +- i--; +- } while (count--); ++ enetc_unwind_tx_frame(tx_ring, count, i); + + return 0; + } diff --git a/queue-6.6/net-enetc-keep-track-of-correct-tx-bd-count-in-enetc_map_tx_tso_buffs.patch b/queue-6.6/net-enetc-keep-track-of-correct-tx-bd-count-in-enetc_map_tx_tso_buffs.patch new file mode 100644 index 0000000000..51e3d412c7 --- /dev/null +++ b/queue-6.6/net-enetc-keep-track-of-correct-tx-bd-count-in-enetc_map_tx_tso_buffs.patch @@ -0,0 +1,72 @@ +From da291996b16ebd10626d4b20288327b743aff110 Mon Sep 17 00:00:00 2001 +From: Wei Fang +Date: Mon, 24 Feb 2025 19:12:45 +0800 +Subject: net: enetc: keep track of correct Tx BD count in enetc_map_tx_tso_buffs() + +From: Wei Fang + +commit da291996b16ebd10626d4b20288327b743aff110 upstream. + +When creating a TSO header, if the skb is VLAN tagged, the extended BD +will be used and the 'count' should be increased by 2 instead of 1. +Otherwise, when an error occurs, less tx_swbd will be freed than the +actual number. + +Fixes: fb8629e2cbfc ("net: enetc: add support for software TSO") +Cc: stable@vger.kernel.org +Suggested-by: Vladimir Oltean +Signed-off-by: Wei Fang +Reviewed-by: Vladimir Oltean +Reviewed-by: Claudiu Manoil +Link: https://patch.msgid.link/20250224111251.1061098-3-wei.fang@nxp.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/freescale/enetc/enetc.c | 16 ++++++++++------ + 1 file changed, 10 insertions(+), 6 deletions(-) + +--- a/drivers/net/ethernet/freescale/enetc/enetc.c ++++ b/drivers/net/ethernet/freescale/enetc/enetc.c +@@ -351,14 +351,15 @@ dma_err: + return 0; + } + +-static void enetc_map_tx_tso_hdr(struct enetc_bdr *tx_ring, struct sk_buff *skb, +- struct enetc_tx_swbd *tx_swbd, +- union enetc_tx_bd *txbd, int *i, int hdr_len, +- int data_len) ++static int enetc_map_tx_tso_hdr(struct enetc_bdr *tx_ring, struct sk_buff *skb, ++ struct enetc_tx_swbd *tx_swbd, ++ union enetc_tx_bd *txbd, int *i, int hdr_len, ++ int data_len) + { + union enetc_tx_bd txbd_tmp; + u8 flags = 0, e_flags = 0; + dma_addr_t addr; ++ int count = 1; + + enetc_clear_tx_bd(&txbd_tmp); + addr = tx_ring->tso_headers_dma + *i * TSO_HEADER_SIZE; +@@ -401,7 +402,10 @@ static void enetc_map_tx_tso_hdr(struct + /* Write the BD */ + txbd_tmp.ext.e_flags = e_flags; + *txbd = txbd_tmp; ++ count++; + } ++ ++ return count; + } + + static int enetc_map_tx_tso_data(struct enetc_bdr *tx_ring, struct sk_buff *skb, +@@ -533,9 +537,9 @@ static int enetc_map_tx_tso_buffs(struct + + /* compute the csum over the L4 header */ + csum = enetc_tso_hdr_csum(&tso, skb, hdr, hdr_len, &pos); +- enetc_map_tx_tso_hdr(tx_ring, skb, tx_swbd, txbd, &i, hdr_len, data_len); ++ count += enetc_map_tx_tso_hdr(tx_ring, skb, tx_swbd, txbd, ++ &i, hdr_len, data_len); + bd_data_num = 0; +- count++; + + while (data_len > 0) { + int size; diff --git a/queue-6.6/net-enetc-update-udp-checksum-when-updating-origintimestamp-field.patch b/queue-6.6/net-enetc-update-udp-checksum-when-updating-origintimestamp-field.patch new file mode 100644 index 0000000000..406323b60b --- /dev/null +++ b/queue-6.6/net-enetc-update-udp-checksum-when-updating-origintimestamp-field.patch @@ -0,0 +1,88 @@ +From bbcbc906ab7b5834c1219cd17a38d78dba904aa0 Mon Sep 17 00:00:00 2001 +From: Wei Fang +Date: Mon, 24 Feb 2025 19:12:48 +0800 +Subject: net: enetc: update UDP checksum when updating originTimestamp field + +From: Wei Fang + +commit bbcbc906ab7b5834c1219cd17a38d78dba904aa0 upstream. + +There is an issue with one-step timestamp based on UDP/IP. The peer will +discard the sync packet because of the wrong UDP checksum. For ENETC v1, +the software needs to update the UDP checksum when updating the +originTimestamp field, so that the hardware can correctly update the UDP +checksum when updating the correction field. Otherwise, the UDP checksum +in the sync packet will be wrong. + +Fixes: 7294380c5211 ("enetc: support PTP Sync packet one-step timestamping") +Cc: stable@vger.kernel.org +Signed-off-by: Wei Fang +Reviewed-by: Vladimir Oltean +Tested-by: Vladimir Oltean +Link: https://patch.msgid.link/20250224111251.1061098-6-wei.fang@nxp.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/freescale/enetc/enetc.c | 41 ++++++++++++++++++++++----- + 1 file changed, 34 insertions(+), 7 deletions(-) + +--- a/drivers/net/ethernet/freescale/enetc/enetc.c ++++ b/drivers/net/ethernet/freescale/enetc/enetc.c +@@ -253,9 +253,11 @@ static int enetc_map_tx_buffs(struct ene + } + + if (do_onestep_tstamp) { +- u32 lo, hi, val; +- u64 sec, nsec; ++ __be32 new_sec_l, new_nsec; ++ u32 lo, hi, nsec, val; ++ __be16 new_sec_h; + u8 *data; ++ u64 sec; + + lo = enetc_rd_hot(hw, ENETC_SICTR0); + hi = enetc_rd_hot(hw, ENETC_SICTR1); +@@ -269,13 +271,38 @@ static int enetc_map_tx_buffs(struct ene + /* Update originTimestamp field of Sync packet + * - 48 bits seconds field + * - 32 bits nanseconds field ++ * ++ * In addition, the UDP checksum needs to be updated ++ * by software after updating originTimestamp field, ++ * otherwise the hardware will calculate the wrong ++ * checksum when updating the correction field and ++ * update it to the packet. + */ + data = skb_mac_header(skb); +- *(__be16 *)(data + offset2) = +- htons((sec >> 32) & 0xffff); +- *(__be32 *)(data + offset2 + 2) = +- htonl(sec & 0xffffffff); +- *(__be32 *)(data + offset2 + 6) = htonl(nsec); ++ new_sec_h = htons((sec >> 32) & 0xffff); ++ new_sec_l = htonl(sec & 0xffffffff); ++ new_nsec = htonl(nsec); ++ if (udp) { ++ struct udphdr *uh = udp_hdr(skb); ++ __be32 old_sec_l, old_nsec; ++ __be16 old_sec_h; ++ ++ old_sec_h = *(__be16 *)(data + offset2); ++ inet_proto_csum_replace2(&uh->check, skb, old_sec_h, ++ new_sec_h, false); ++ ++ old_sec_l = *(__be32 *)(data + offset2 + 2); ++ inet_proto_csum_replace4(&uh->check, skb, old_sec_l, ++ new_sec_l, false); ++ ++ old_nsec = *(__be32 *)(data + offset2 + 6); ++ inet_proto_csum_replace4(&uh->check, skb, old_nsec, ++ new_nsec, false); ++ } ++ ++ *(__be16 *)(data + offset2) = new_sec_h; ++ *(__be32 *)(data + offset2 + 2) = new_sec_l; ++ *(__be32 *)(data + offset2 + 6) = new_nsec; + + /* Configure single-step register */ + val = ENETC_PM0_SINGLE_STEP_EN; diff --git a/queue-6.6/perf-core-add-rcu-read-lock-protection-to-perf_iterate_ctx.patch b/queue-6.6/perf-core-add-rcu-read-lock-protection-to-perf_iterate_ctx.patch new file mode 100644 index 0000000000..dbce93343e --- /dev/null +++ b/queue-6.6/perf-core-add-rcu-read-lock-protection-to-perf_iterate_ctx.patch @@ -0,0 +1,63 @@ +From 0fe8813baf4b2e865d3b2c735ce1a15b86002c74 Mon Sep 17 00:00:00 2001 +From: Breno Leitao +Date: Fri, 17 Jan 2025 06:41:07 -0800 +Subject: perf/core: Add RCU read lock protection to perf_iterate_ctx() + +From: Breno Leitao + +commit 0fe8813baf4b2e865d3b2c735ce1a15b86002c74 upstream. + +The perf_iterate_ctx() function performs RCU list traversal but +currently lacks RCU read lock protection. This causes lockdep warnings +when running perf probe with unshare(1) under CONFIG_PROVE_RCU_LIST=y: + + WARNING: suspicious RCU usage + kernel/events/core.c:8168 RCU-list traversed in non-reader section!! + + Call Trace: + lockdep_rcu_suspicious + ? perf_event_addr_filters_apply + perf_iterate_ctx + perf_event_exec + begin_new_exec + ? load_elf_phdrs + load_elf_binary + ? lock_acquire + ? find_held_lock + ? bprm_execve + bprm_execve + do_execveat_common.isra.0 + __x64_sys_execve + do_syscall_64 + entry_SYSCALL_64_after_hwframe + +This protection was previously present but was removed in commit +bd2756811766 ("perf: Rewrite core context handling"). Add back the +necessary rcu_read_lock()/rcu_read_unlock() pair around +perf_iterate_ctx() call in perf_event_exec(). + +[ mingo: Use scoped_guard() as suggested by Peter ] + +Fixes: bd2756811766 ("perf: Rewrite core context handling") +Signed-off-by: Breno Leitao +Signed-off-by: Ingo Molnar +Acked-by: Peter Zijlstra (Intel) +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20250117-fix_perf_rcu-v1-1-13cb9210fc6a@debian.org +Signed-off-by: Greg Kroah-Hartman +--- + kernel/events/core.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/kernel/events/core.c ++++ b/kernel/events/core.c +@@ -8113,7 +8113,8 @@ void perf_event_exec(void) + + perf_event_enable_on_exec(ctx); + perf_event_remove_on_exec(ctx); +- perf_iterate_ctx(ctx, perf_event_addr_filters_exec, NULL, true); ++ scoped_guard(rcu) ++ perf_iterate_ctx(ctx, perf_event_addr_filters_exec, NULL, true); + + perf_unpin_context(ctx); + put_ctx(ctx); diff --git a/queue-6.6/perf-core-fix-low-freq-setting-via-ioc_period.patch b/queue-6.6/perf-core-fix-low-freq-setting-via-ioc_period.patch new file mode 100644 index 0000000000..327d387e8b --- /dev/null +++ b/queue-6.6/perf-core-fix-low-freq-setting-via-ioc_period.patch @@ -0,0 +1,59 @@ +From 0d39844150546fa1415127c5fbae26db64070dd3 Mon Sep 17 00:00:00 2001 +From: Kan Liang +Date: Fri, 17 Jan 2025 07:19:12 -0800 +Subject: perf/core: Fix low freq setting via IOC_PERIOD + +From: Kan Liang + +commit 0d39844150546fa1415127c5fbae26db64070dd3 upstream. + +A low attr::freq value cannot be set via IOC_PERIOD on some platforms. + +The perf_event_check_period() introduced in: + + 81ec3f3c4c4d ("perf/x86: Add check_period PMU callback") + +was intended to check the period, rather than the frequency. +A low frequency may be mistakenly rejected by limit_period(). + +Fix it. + +Fixes: 81ec3f3c4c4d ("perf/x86: Add check_period PMU callback") +Signed-off-by: Kan Liang +Signed-off-by: Ingo Molnar +Reviewed-by: Ravi Bangoria +Cc: Peter Zijlstra +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20250117151913.3043942-2-kan.liang@linux.intel.com +Closes: https://lore.kernel.org/lkml/20250115154949.3147-1-ravi.bangoria@amd.com/ +Signed-off-by: Greg Kroah-Hartman +--- + kernel/events/core.c | 17 +++++++++-------- + 1 file changed, 9 insertions(+), 8 deletions(-) + +--- a/kernel/events/core.c ++++ b/kernel/events/core.c +@@ -5861,14 +5861,15 @@ static int _perf_event_period(struct per + if (!value) + return -EINVAL; + +- if (event->attr.freq && value > sysctl_perf_event_sample_rate) +- return -EINVAL; +- +- if (perf_event_check_period(event, value)) +- return -EINVAL; +- +- if (!event->attr.freq && (value & (1ULL << 63))) +- return -EINVAL; ++ if (event->attr.freq) { ++ if (value > sysctl_perf_event_sample_rate) ++ return -EINVAL; ++ } else { ++ if (perf_event_check_period(event, value)) ++ return -EINVAL; ++ if (value & (1ULL << 63)) ++ return -EINVAL; ++ } + + event_function_call(event, __perf_event_period, &value); + diff --git a/queue-6.6/perf-x86-fix-low-freqency-setting-issue.patch b/queue-6.6/perf-x86-fix-low-freqency-setting-issue.patch new file mode 100644 index 0000000000..038b11b8c8 --- /dev/null +++ b/queue-6.6/perf-x86-fix-low-freqency-setting-issue.patch @@ -0,0 +1,48 @@ +From 88ec7eedbbd21cad38707620ad6c48a4e9a87c18 Mon Sep 17 00:00:00 2001 +From: Kan Liang +Date: Fri, 17 Jan 2025 07:19:11 -0800 +Subject: perf/x86: Fix low freqency setting issue + +From: Kan Liang + +commit 88ec7eedbbd21cad38707620ad6c48a4e9a87c18 upstream. + +Perf doesn't work at low frequencies: + + $ perf record -e cpu_core/instructions/ppp -F 120 + Error: + The sys_perf_event_open() syscall returned with 22 (Invalid argument) + for event (cpu_core/instructions/ppp). + "dmesg | grep -i perf" may provide additional information. + +The limit_period() check avoids a low sampling period on a counter. It +doesn't intend to limit the frequency. + +The check in the x86_pmu_hw_config() should be limited to non-freq mode. +The attr.sample_period and attr.sample_freq are union. The +attr.sample_period should not be used to indicate the frequency mode. + +Fixes: c46e665f0377 ("perf/x86: Add INST_RETIRED.ALL workarounds") +Signed-off-by: Kan Liang +Signed-off-by: Ingo Molnar +Reviewed-by: Ravi Bangoria +Cc: Peter Zijlstra +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20250117151913.3043942-1-kan.liang@linux.intel.com +Closes: https://lore.kernel.org/lkml/20250115154949.3147-1-ravi.bangoria@amd.com/ +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/events/core.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/x86/events/core.c ++++ b/arch/x86/events/core.c +@@ -623,7 +623,7 @@ int x86_pmu_hw_config(struct perf_event + if (event->attr.type == event->pmu->type) + event->hw.config |= event->attr.config & X86_RAW_EVENT_MASK; + +- if (event->attr.sample_period && x86_pmu.limit_period) { ++ if (!event->attr.freq && x86_pmu.limit_period) { + s64 left = event->attr.sample_period; + x86_pmu.limit_period(event, &left); + if (left > event->attr.sample_period) diff --git a/queue-6.6/phy-exynos5-usbdrd-fix-mpll_multiplier-and-ssc_refclksel-masks-in-refclk.patch b/queue-6.6/phy-exynos5-usbdrd-fix-mpll_multiplier-and-ssc_refclksel-masks-in-refclk.patch new file mode 100644 index 0000000000..8615b5d4a0 --- /dev/null +++ b/queue-6.6/phy-exynos5-usbdrd-fix-mpll_multiplier-and-ssc_refclksel-masks-in-refclk.patch @@ -0,0 +1,53 @@ +From e2158c953c973adb49383ddea2504faf08d375b7 Mon Sep 17 00:00:00 2001 +From: Kaustabh Chakraborty +Date: Sun, 9 Feb 2025 00:29:30 +0530 +Subject: phy: exynos5-usbdrd: fix MPLL_MULTIPLIER and SSC_REFCLKSEL masks in refclk + +From: Kaustabh Chakraborty + +commit e2158c953c973adb49383ddea2504faf08d375b7 upstream. + +In exynos5_usbdrd_{pipe3,utmi}_set_refclk(), the masks +PHYCLKRST_MPLL_MULTIPLIER_MASK and PHYCLKRST_SSC_REFCLKSEL_MASK are not +inverted when applied to the register values. Fix it. + +Cc: stable@vger.kernel.org +Fixes: 59025887fb08 ("phy: Add new Exynos5 USB 3.0 PHY driver") +Signed-off-by: Kaustabh Chakraborty +Reviewed-by: Krzysztof Kozlowski +Reviewed-by: Anand Moon +Link: https://lore.kernel.org/r/20250209-exynos5-usbdrd-masks-v1-1-4f7f83f323d7@disroot.org +Signed-off-by: Vinod Koul +Signed-off-by: Greg Kroah-Hartman +--- + drivers/phy/samsung/phy-exynos5-usbdrd.c | 12 ++++++------ + 1 file changed, 6 insertions(+), 6 deletions(-) + +--- a/drivers/phy/samsung/phy-exynos5-usbdrd.c ++++ b/drivers/phy/samsung/phy-exynos5-usbdrd.c +@@ -319,9 +319,9 @@ exynos5_usbdrd_pipe3_set_refclk(struct p + reg |= PHYCLKRST_REFCLKSEL_EXT_REFCLK; + + /* FSEL settings corresponding to reference clock */ +- reg &= ~PHYCLKRST_FSEL_PIPE_MASK | +- PHYCLKRST_MPLL_MULTIPLIER_MASK | +- PHYCLKRST_SSC_REFCLKSEL_MASK; ++ reg &= ~(PHYCLKRST_FSEL_PIPE_MASK | ++ PHYCLKRST_MPLL_MULTIPLIER_MASK | ++ PHYCLKRST_SSC_REFCLKSEL_MASK); + switch (phy_drd->extrefclk) { + case EXYNOS5_FSEL_50MHZ: + reg |= (PHYCLKRST_MPLL_MULTIPLIER_50M_REF | +@@ -363,9 +363,9 @@ exynos5_usbdrd_utmi_set_refclk(struct ph + reg &= ~PHYCLKRST_REFCLKSEL_MASK; + reg |= PHYCLKRST_REFCLKSEL_EXT_REFCLK; + +- reg &= ~PHYCLKRST_FSEL_UTMI_MASK | +- PHYCLKRST_MPLL_MULTIPLIER_MASK | +- PHYCLKRST_SSC_REFCLKSEL_MASK; ++ reg &= ~(PHYCLKRST_FSEL_UTMI_MASK | ++ PHYCLKRST_MPLL_MULTIPLIER_MASK | ++ PHYCLKRST_SSC_REFCLKSEL_MASK); + reg |= PHYCLKRST_FSEL(phy_drd->extrefclk); + + return reg; diff --git a/queue-6.6/phy-tegra-xusb-reset-vbus-id-override.patch b/queue-6.6/phy-tegra-xusb-reset-vbus-id-override.patch new file mode 100644 index 0000000000..6acd272c25 --- /dev/null +++ b/queue-6.6/phy-tegra-xusb-reset-vbus-id-override.patch @@ -0,0 +1,69 @@ +From 55f1a5f7c97c3c92ba469e16991a09274410ceb7 Mon Sep 17 00:00:00 2001 +From: BH Hsieh +Date: Wed, 22 Jan 2025 18:59:43 +0800 +Subject: phy: tegra: xusb: reset VBUS & ID OVERRIDE + +From: BH Hsieh + +commit 55f1a5f7c97c3c92ba469e16991a09274410ceb7 upstream. + +Observed VBUS_OVERRIDE & ID_OVERRIDE might be programmed +with unexpected value prior to XUSB PADCTL driver, this +could also occur in virtualization scenario. + +For example, UEFI firmware programs ID_OVERRIDE=GROUNDED to set +a type-c port to host mode and keeps the value to kernel. +If the type-c port is connected a usb host, below errors can be +observed right after usb host mode driver gets probed. The errors +would keep until usb role class driver detects the type-c port +as device mode and notifies usb device mode driver to set both +ID_OVERRIDE and VBUS_OVERRIDE to correct value by XUSB PADCTL +driver. + +[ 173.765814] usb usb3-port2: Cannot enable. Maybe the USB cable is bad? +[ 173.765837] usb usb3-port2: config error + +Taking virtualization into account, asserting XUSB PADCTL +reset would break XUSB functions used by other guest OS, +hence only reset VBUS & ID OVERRIDE of the port in +utmi_phy_init. + +Fixes: bbf711682cd5 ("phy: tegra: xusb: Add Tegra186 support") +Cc: stable@vger.kernel.org +Change-Id: Ic63058d4d49b4a1f8f9ab313196e20ad131cc591 +Signed-off-by: BH Hsieh +Signed-off-by: Henry Lin +Link: https://lore.kernel.org/r/20250122105943.8057-1-henryl@nvidia.com +Signed-off-by: Vinod Koul +Signed-off-by: Greg Kroah-Hartman +--- + drivers/phy/tegra/xusb-tegra186.c | 11 +++++++++++ + 1 file changed, 11 insertions(+) + +--- a/drivers/phy/tegra/xusb-tegra186.c ++++ b/drivers/phy/tegra/xusb-tegra186.c +@@ -928,6 +928,7 @@ static int tegra186_utmi_phy_init(struct + unsigned int index = lane->index; + struct device *dev = padctl->dev; + int err; ++ u32 reg; + + port = tegra_xusb_find_usb2_port(padctl, index); + if (!port) { +@@ -935,6 +936,16 @@ static int tegra186_utmi_phy_init(struct + return -ENODEV; + } + ++ if (port->mode == USB_DR_MODE_OTG || ++ port->mode == USB_DR_MODE_PERIPHERAL) { ++ /* reset VBUS&ID OVERRIDE */ ++ reg = padctl_readl(padctl, USB2_VBUS_ID); ++ reg &= ~VBUS_OVERRIDE; ++ reg &= ~ID_OVERRIDE(~0); ++ reg |= ID_OVERRIDE_FLOATING; ++ padctl_writel(padctl, reg, USB2_VBUS_ID); ++ } ++ + if (port->supply && port->mode == USB_DR_MODE_HOST) { + err = regulator_enable(port->supply); + if (err) { diff --git a/queue-6.6/rcuref-plug-slowpath-race-in-rcuref_put.patch b/queue-6.6/rcuref-plug-slowpath-race-in-rcuref_put.patch new file mode 100644 index 0000000000..d8c2f1ddae --- /dev/null +++ b/queue-6.6/rcuref-plug-slowpath-race-in-rcuref_put.patch @@ -0,0 +1,122 @@ +From b9a49520679e98700d3d89689cc91c08a1c88c1d Mon Sep 17 00:00:00 2001 +From: Thomas Gleixner +Date: Sun, 19 Jan 2025 00:55:32 +0100 +Subject: rcuref: Plug slowpath race in rcuref_put() + +From: Thomas Gleixner + +commit b9a49520679e98700d3d89689cc91c08a1c88c1d upstream. + +Kernel test robot reported an "imbalanced put" in the rcuref_put() slow +path, which turned out to be a false positive. Consider the following race: + + ref = 0 (via rcuref_init(ref, 1)) + T1 T2 + rcuref_put(ref) + -> atomic_add_negative_release(-1, ref) # ref -> 0xffffffff + -> rcuref_put_slowpath(ref) + rcuref_get(ref) + -> atomic_add_negative_relaxed(1, &ref->refcnt) + -> return true; # ref -> 0 + + rcuref_put(ref) + -> atomic_add_negative_release(-1, ref) # ref -> 0xffffffff + -> rcuref_put_slowpath() + + -> cnt = atomic_read(&ref->refcnt); # cnt -> 0xffffffff / RCUREF_NOREF + -> atomic_try_cmpxchg_release(&ref->refcnt, &cnt, RCUREF_DEAD)) # ref -> 0xe0000000 / RCUREF_DEAD + -> return true + -> cnt = atomic_read(&ref->refcnt); # cnt -> 0xe0000000 / RCUREF_DEAD + -> if (cnt > RCUREF_RELEASED) # 0xe0000000 > 0xc0000000 + -> WARN_ONCE(cnt >= RCUREF_RELEASED, "rcuref - imbalanced put()") + +The problem is the additional read in the slow path (after it +decremented to RCUREF_NOREF) which can happen after the counter has been +marked RCUREF_DEAD. + +Prevent this by reusing the return value of the decrement. Now every "final" +put uses RCUREF_NOREF in the slow path and attempts the final cmpxchg() to +RCUREF_DEAD. + +[ bigeasy: Add changelog ] + +Fixes: ee1ee6db07795 ("atomics: Provide rcuref - scalable reference counting") +Reported-by: kernel test robot +Debugged-by: Sebastian Andrzej Siewior +Signed-off-by: Thomas Gleixner +Signed-off-by: Sebastian Andrzej Siewior +Signed-off-by: Thomas Gleixner +Reviewed-by: Sebastian Andrzej Siewior +Cc: stable@vger.kernel.org +Closes: https://lore.kernel.org/oe-lkp/202412311453.9d7636a2-lkp@intel.com +Signed-off-by: Greg Kroah-Hartman +--- + include/linux/rcuref.h | 9 ++++++--- + lib/rcuref.c | 5 ++--- + 2 files changed, 8 insertions(+), 6 deletions(-) + +diff --git a/include/linux/rcuref.h b/include/linux/rcuref.h +index 2c8bfd0f1b6b..6322d8c1c6b4 100644 +--- a/include/linux/rcuref.h ++++ b/include/linux/rcuref.h +@@ -71,27 +71,30 @@ static inline __must_check bool rcuref_get(rcuref_t *ref) + return rcuref_get_slowpath(ref); + } + +-extern __must_check bool rcuref_put_slowpath(rcuref_t *ref); ++extern __must_check bool rcuref_put_slowpath(rcuref_t *ref, unsigned int cnt); + + /* + * Internal helper. Do not invoke directly. + */ + static __always_inline __must_check bool __rcuref_put(rcuref_t *ref) + { ++ int cnt; ++ + RCU_LOCKDEP_WARN(!rcu_read_lock_held() && preemptible(), + "suspicious rcuref_put_rcusafe() usage"); + /* + * Unconditionally decrease the reference count. The saturation and + * dead zones provide enough tolerance for this. + */ +- if (likely(!atomic_add_negative_release(-1, &ref->refcnt))) ++ cnt = atomic_sub_return_release(1, &ref->refcnt); ++ if (likely(cnt >= 0)) + return false; + + /* + * Handle the last reference drop and cases inside the saturation + * and dead zones. + */ +- return rcuref_put_slowpath(ref); ++ return rcuref_put_slowpath(ref, cnt); + } + + /** +diff --git a/lib/rcuref.c b/lib/rcuref.c +index 97f300eca927..5bd726b71e39 100644 +--- a/lib/rcuref.c ++++ b/lib/rcuref.c +@@ -220,6 +220,7 @@ EXPORT_SYMBOL_GPL(rcuref_get_slowpath); + /** + * rcuref_put_slowpath - Slowpath of __rcuref_put() + * @ref: Pointer to the reference count ++ * @cnt: The resulting value of the fastpath decrement + * + * Invoked when the reference count is outside of the valid zone. + * +@@ -233,10 +234,8 @@ EXPORT_SYMBOL_GPL(rcuref_get_slowpath); + * with a concurrent get()/put() pair. Caller is not allowed to + * deconstruct the protected object. + */ +-bool rcuref_put_slowpath(rcuref_t *ref) ++bool rcuref_put_slowpath(rcuref_t *ref, unsigned int cnt) + { +- unsigned int cnt = atomic_read(&ref->refcnt); +- + /* Did this drop the last reference? */ + if (likely(cnt == RCUREF_NOREF)) { + /* +-- +2.48.1 + diff --git a/queue-6.6/riscv-futex-sign-extend-compare-value-in-atomic-cmpxchg.patch b/queue-6.6/riscv-futex-sign-extend-compare-value-in-atomic-cmpxchg.patch new file mode 100644 index 0000000000..a2ae01d517 --- /dev/null +++ b/queue-6.6/riscv-futex-sign-extend-compare-value-in-atomic-cmpxchg.patch @@ -0,0 +1,40 @@ +From 599c44cd21f4967774e0acf58f734009be4aea9a Mon Sep 17 00:00:00 2001 +From: Andreas Schwab +Date: Mon, 3 Feb 2025 11:06:00 +0100 +Subject: riscv/futex: sign extend compare value in atomic cmpxchg +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Andreas Schwab + +commit 599c44cd21f4967774e0acf58f734009be4aea9a upstream. + +Make sure the compare value in the lr/sc loop is sign extended to match +what lr.w does. Fortunately, due to the compiler keeping the register +contents sign extended anyway the lack of the explicit extension didn't +result in wrong code so far, but this cannot be relied upon. + +Fixes: b90edb33010b ("RISC-V: Add futex support.") +Signed-off-by: Andreas Schwab +Reviewed-by: Alexandre Ghiti +Reviewed-by: Björn Töpel +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/mvmfrkv2vhz.fsf@suse.de +Signed-off-by: Palmer Dabbelt +Signed-off-by: Greg Kroah-Hartman +--- + arch/riscv/include/asm/futex.h | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/riscv/include/asm/futex.h ++++ b/arch/riscv/include/asm/futex.h +@@ -93,7 +93,7 @@ futex_atomic_cmpxchg_inatomic(u32 *uval, + _ASM_EXTABLE_UACCESS_ERR(1b, 3b, %[r]) \ + _ASM_EXTABLE_UACCESS_ERR(2b, 3b, %[r]) \ + : [r] "+r" (ret), [v] "=&r" (val), [u] "+m" (*uaddr), [t] "=&r" (tmp) +- : [ov] "Jr" (oldval), [nv] "Jr" (newval) ++ : [ov] "Jr" ((long)(int)oldval), [nv] "Jr" (newval) + : "memory"); + __disable_user_access(); + diff --git a/queue-6.6/riscv-signal-fix-signal-frame-size.patch b/queue-6.6/riscv-signal-fix-signal-frame-size.patch new file mode 100644 index 0000000000..c0784beabb --- /dev/null +++ b/queue-6.6/riscv-signal-fix-signal-frame-size.patch @@ -0,0 +1,42 @@ +From aa49bc2ca8524186ceb0811c23a7f00c3dea6987 Mon Sep 17 00:00:00 2001 +From: Yong-Xuan Wang +Date: Fri, 20 Dec 2024 16:39:23 +0800 +Subject: riscv: signal: fix signal frame size + +From: Yong-Xuan Wang + +commit aa49bc2ca8524186ceb0811c23a7f00c3dea6987 upstream. + +The signal context of certain RISC-V extensions will be appended after +struct __riscv_extra_ext_header, which already includes an empty context +header. Therefore, there is no need to preserve a separate hdr for the +END of signal context. + +Fixes: 8ee0b41898fa ("riscv: signal: Add sigcontext save/restore for vector") +Signed-off-by: Yong-Xuan Wang +Reviewed-by: Zong Li +Reviewed-by: Andy Chiu +Reviewed-by: Alexandre Ghiti +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20241220083926.19453-2-yongxuan.wang@sifive.com +Signed-off-by: Palmer Dabbelt +Signed-off-by: Greg Kroah-Hartman +--- + arch/riscv/kernel/signal.c | 6 ------ + 1 file changed, 6 deletions(-) + +--- a/arch/riscv/kernel/signal.c ++++ b/arch/riscv/kernel/signal.c +@@ -211,12 +211,6 @@ static size_t get_rt_frame_size(bool cal + if (cal_all || riscv_v_vstate_query(task_pt_regs(current))) + total_context_size += riscv_v_sc_size; + } +- /* +- * Preserved a __riscv_ctx_hdr for END signal context header if an +- * extension uses __riscv_extra_ext_header +- */ +- if (total_context_size) +- total_context_size += sizeof(struct __riscv_ctx_hdr); + + frame_size += total_context_size; + diff --git a/queue-6.6/rseq-selftests-fix-riscv-rseq_offset_deref_addv-inline-asm.patch b/queue-6.6/rseq-selftests-fix-riscv-rseq_offset_deref_addv-inline-asm.patch new file mode 100644 index 0000000000..1d0ef35fbe --- /dev/null +++ b/queue-6.6/rseq-selftests-fix-riscv-rseq_offset_deref_addv-inline-asm.patch @@ -0,0 +1,70 @@ +From 713e788c0e07e185fd44dd581f74855ef149722f Mon Sep 17 00:00:00 2001 +From: Stafford Horne +Date: Tue, 14 Jan 2025 17:07:21 +0000 +Subject: rseq/selftests: Fix riscv rseq_offset_deref_addv inline asm + +From: Stafford Horne + +commit 713e788c0e07e185fd44dd581f74855ef149722f upstream. + +When working on OpenRISC support for restartable sequences I noticed +and fixed these two issues with the riscv support bits. + + 1 The 'inc' argument to RSEQ_ASM_OP_R_DEREF_ADDV was being implicitly + passed to the macro. Fix this by adding 'inc' to the list of macro + arguments. + 2 The inline asm input constraints for 'inc' and 'off' use "er", The + riscv gcc port does not have an "e" constraint, this looks to be + copied from the x86 port. Fix this by just using an "r" constraint. + +I have compile tested this only for riscv. However, the same fixes I +use in the OpenRISC rseq selftests and everything passes with no issues. + +Fixes: 171586a6ab66 ("selftests/rseq: riscv: Template memory ordering and percpu access mode") +Signed-off-by: Stafford Horne +Tested-by: Charlie Jenkins +Reviewed-by: Charlie Jenkins +Reviewed-by: Mathieu Desnoyers +Acked-by: Shuah Khan +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20250114170721.3613280-1-shorne@gmail.com +Signed-off-by: Palmer Dabbelt +Signed-off-by: Greg Kroah-Hartman +--- + tools/testing/selftests/rseq/rseq-riscv-bits.h | 6 +++--- + tools/testing/selftests/rseq/rseq-riscv.h | 2 +- + 2 files changed, 4 insertions(+), 4 deletions(-) + +--- a/tools/testing/selftests/rseq/rseq-riscv-bits.h ++++ b/tools/testing/selftests/rseq/rseq-riscv-bits.h +@@ -243,7 +243,7 @@ int RSEQ_TEMPLATE_IDENTIFIER(rseq_offset + #ifdef RSEQ_COMPARE_TWICE + RSEQ_ASM_CMP_CPU_ID(cpu_id, current_cpu_id, "%l[error1]") + #endif +- RSEQ_ASM_OP_R_DEREF_ADDV(ptr, off, 3) ++ RSEQ_ASM_OP_R_DEREF_ADDV(ptr, off, inc, 3) + RSEQ_INJECT_ASM(4) + RSEQ_ASM_DEFINE_ABORT(4, abort) + : /* gcc asm goto does not allow outputs */ +@@ -251,8 +251,8 @@ int RSEQ_TEMPLATE_IDENTIFIER(rseq_offset + [current_cpu_id] "m" (rseq_get_abi()->RSEQ_TEMPLATE_CPU_ID_FIELD), + [rseq_cs] "m" (rseq_get_abi()->rseq_cs.arch.ptr), + [ptr] "r" (ptr), +- [off] "er" (off), +- [inc] "er" (inc) ++ [off] "r" (off), ++ [inc] "r" (inc) + RSEQ_INJECT_INPUT + : "memory", RSEQ_ASM_TMP_REG_1 + RSEQ_INJECT_CLOBBER +--- a/tools/testing/selftests/rseq/rseq-riscv.h ++++ b/tools/testing/selftests/rseq/rseq-riscv.h +@@ -158,7 +158,7 @@ do { \ + "bnez " RSEQ_ASM_TMP_REG_1 ", 222b\n" \ + "333:\n" + +-#define RSEQ_ASM_OP_R_DEREF_ADDV(ptr, off, post_commit_label) \ ++#define RSEQ_ASM_OP_R_DEREF_ADDV(ptr, off, inc, post_commit_label) \ + "mv " RSEQ_ASM_TMP_REG_1 ", %[" __rseq_str(ptr) "]\n" \ + RSEQ_ASM_OP_R_ADD(off) \ + REG_L RSEQ_ASM_TMP_REG_1 ", 0(" RSEQ_ASM_TMP_REG_1 ")\n" \ diff --git a/queue-6.6/sched-core-prevent-rescheduling-when-interrupts-are-disabled.patch b/queue-6.6/sched-core-prevent-rescheduling-when-interrupts-are-disabled.patch new file mode 100644 index 0000000000..1fc4248673 --- /dev/null +++ b/queue-6.6/sched-core-prevent-rescheduling-when-interrupts-are-disabled.patch @@ -0,0 +1,85 @@ +From 82c387ef7568c0d96a918a5a78d9cad6256cfa15 Mon Sep 17 00:00:00 2001 +From: Thomas Gleixner +Date: Mon, 16 Dec 2024 14:20:56 +0100 +Subject: sched/core: Prevent rescheduling when interrupts are disabled + +From: Thomas Gleixner + +commit 82c387ef7568c0d96a918a5a78d9cad6256cfa15 upstream. + +David reported a warning observed while loop testing kexec jump: + + Interrupts enabled after irqrouter_resume+0x0/0x50 + WARNING: CPU: 0 PID: 560 at drivers/base/syscore.c:103 syscore_resume+0x18a/0x220 + kernel_kexec+0xf6/0x180 + __do_sys_reboot+0x206/0x250 + do_syscall_64+0x95/0x180 + +The corresponding interrupt flag trace: + + hardirqs last enabled at (15573): [] __up_console_sem+0x7e/0x90 + hardirqs last disabled at (15580): [] __up_console_sem+0x63/0x90 + +That means __up_console_sem() was invoked with interrupts enabled. Further +instrumentation revealed that in the interrupt disabled section of kexec +jump one of the syscore_suspend() callbacks woke up a task, which set the +NEED_RESCHED flag. A later callback in the resume path invoked +cond_resched() which in turn led to the invocation of the scheduler: + + __cond_resched+0x21/0x60 + down_timeout+0x18/0x60 + acpi_os_wait_semaphore+0x4c/0x80 + acpi_ut_acquire_mutex+0x3d/0x100 + acpi_ns_get_node+0x27/0x60 + acpi_ns_evaluate+0x1cb/0x2d0 + acpi_rs_set_srs_method_data+0x156/0x190 + acpi_pci_link_set+0x11c/0x290 + irqrouter_resume+0x54/0x60 + syscore_resume+0x6a/0x200 + kernel_kexec+0x145/0x1c0 + __do_sys_reboot+0xeb/0x240 + do_syscall_64+0x95/0x180 + +This is a long standing problem, which probably got more visible with +the recent printk changes. Something does a task wakeup and the +scheduler sets the NEED_RESCHED flag. cond_resched() sees it set and +invokes schedule() from a completely bogus context. The scheduler +enables interrupts after context switching, which causes the above +warning at the end. + +Quite some of the code paths in syscore_suspend()/resume() can result in +triggering a wakeup with the exactly same consequences. They might not +have done so yet, but as they share a lot of code with normal operations +it's just a question of time. + +The problem only affects the PREEMPT_NONE and PREEMPT_VOLUNTARY scheduling +models. Full preemption is not affected as cond_resched() is disabled and +the preemption check preemptible() takes the interrupt disabled flag into +account. + +Cure the problem by adding a corresponding check into cond_resched(). + +Reported-by: David Woodhouse +Suggested-by: Peter Zijlstra +Signed-off-by: Thomas Gleixner +Signed-off-by: Ingo Molnar +Tested-by: David Woodhouse +Cc: Linus Torvalds +Cc: stable@vger.kernel.org +Closes: https://lore.kernel.org/all/7717fe2ac0ce5f0a2c43fdab8b11f4483d54a2a4.camel@infradead.org +Signed-off-by: Greg Kroah-Hartman +--- + kernel/sched/core.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/kernel/sched/core.c ++++ b/kernel/sched/core.c +@@ -8561,7 +8561,7 @@ SYSCALL_DEFINE0(sched_yield) + #if !defined(CONFIG_PREEMPTION) || defined(CONFIG_PREEMPT_DYNAMIC) + int __sched __cond_resched(void) + { +- if (should_resched(0)) { ++ if (should_resched(0) && !irqs_disabled()) { + preempt_schedule_common(); + return 1; + } diff --git a/queue-6.6/scsi-ufs-core-bsg-fix-crash-when-arpmb-command-fails.patch b/queue-6.6/scsi-ufs-core-bsg-fix-crash-when-arpmb-command-fails.patch new file mode 100644 index 0000000000..7f1905d69b --- /dev/null +++ b/queue-6.6/scsi-ufs-core-bsg-fix-crash-when-arpmb-command-fails.patch @@ -0,0 +1,79 @@ +From f27a95845b01e86d67c8b014b4f41bd3327daa63 Mon Sep 17 00:00:00 2001 +From: Arthur Simchaev +Date: Thu, 20 Feb 2025 16:20:39 +0200 +Subject: scsi: ufs: core: bsg: Fix crash when arpmb command fails + +From: Arthur Simchaev + +commit f27a95845b01e86d67c8b014b4f41bd3327daa63 upstream. + +If the device doesn't support arpmb we'll crash due to copying user data in +bsg_transport_sg_io_fn(). + +In the case where ufs_bsg_exec_advanced_rpmb_req() returns an error, do not +set the job's reply_len. + +Memory crash backtrace: +3,1290,531166405,-;ufshcd 0000:00:12.5: ARPMB OP failed: error code -22 + +4,1308,531166555,-;Call Trace: + +4,1309,531166559,-; + +4,1310,531166565,-; ? show_regs+0x6d/0x80 + +4,1311,531166575,-; ? die+0x37/0xa0 + +4,1312,531166583,-; ? do_trap+0xd4/0xf0 + +4,1313,531166593,-; ? do_error_trap+0x71/0xb0 + +4,1314,531166601,-; ? usercopy_abort+0x6c/0x80 + +4,1315,531166610,-; ? exc_invalid_op+0x52/0x80 + +4,1316,531166622,-; ? usercopy_abort+0x6c/0x80 + +4,1317,531166630,-; ? asm_exc_invalid_op+0x1b/0x20 + +4,1318,531166643,-; ? usercopy_abort+0x6c/0x80 + +4,1319,531166652,-; __check_heap_object+0xe3/0x120 + +4,1320,531166661,-; check_heap_object+0x185/0x1d0 + +4,1321,531166670,-; __check_object_size.part.0+0x72/0x150 + +4,1322,531166679,-; __check_object_size+0x23/0x30 + +4,1323,531166688,-; bsg_transport_sg_io_fn+0x314/0x3b0 + +Fixes: 6ff265fc5ef6 ("scsi: ufs: core: bsg: Add advanced RPMB support in ufs_bsg") +Cc: stable@vger.kernel.org +Reviewed-by: Bean Huo +Signed-off-by: Arthur Simchaev +Link: https://lore.kernel.org/r/20250220142039.250992-1-arthur.simchaev@sandisk.com +Reviewed-by: Bart Van Assche +Signed-off-by: Martin K. Petersen +Signed-off-by: Greg Kroah-Hartman +--- + drivers/ufs/core/ufs_bsg.c | 6 ++++-- + 1 file changed, 4 insertions(+), 2 deletions(-) + +--- a/drivers/ufs/core/ufs_bsg.c ++++ b/drivers/ufs/core/ufs_bsg.c +@@ -194,10 +194,12 @@ out: + ufshcd_rpm_put_sync(hba); + kfree(buff); + bsg_reply->result = ret; +- job->reply_len = !rpmb ? sizeof(struct ufs_bsg_reply) : sizeof(struct ufs_rpmb_reply); + /* complete the job here only if no error */ +- if (ret == 0) ++ if (ret == 0) { ++ job->reply_len = rpmb ? sizeof(struct ufs_rpmb_reply) : ++ sizeof(struct ufs_bsg_reply); + bsg_job_done(job, ret, bsg_reply->reply_payload_rcv_len); ++ } + + return ret; + } diff --git a/queue-6.6/series b/queue-6.6/series index 5a5950edd4..ef9b6543c3 100644 --- a/queue-6.6/series +++ b/queue-6.6/series @@ -58,3 +58,32 @@ riscv-kvm-introduce-mp_state_lock-to-avoid-lock-inve.patch riscv-kvm-fix-hart-suspend-status-check.patch riscv-kvm-fix-sbi-ipi-error-generation.patch riscv-kvm-fix-sbi-time-error-generation.patch +tracing-fix-bad-hist-from-corrupting-named_triggers-list.patch +ftrace-avoid-potential-division-by-zero-in-function_stat_show.patch +alsa-usb-audio-re-add-sample-rate-quirk-for-pioneer-djm-900nxs2.patch +alsa-hda-realtek-fix-microphone-regression-on-asus-n705ud.patch +kvm-nvmx-process-events-on-nested-vm-exit-if-injectable-irq-or-nmi-is-pending.patch +perf-core-add-rcu-read-lock-protection-to-perf_iterate_ctx.patch +perf-x86-fix-low-freqency-setting-issue.patch +perf-core-fix-low-freq-setting-via-ioc_period.patch +drm-amd-display-disable-psr-su-on-edp-panels.patch +drm-amd-display-fix-hpd-after-gpu-reset.patch +i2c-npcm-disable-interrupt-enable-bit-before-devm_request_irq.patch +i2c-ls2x-fix-frequency-division-register-access.patch +usbnet-gl620a-fix-endpoint-checking-in-genelink_bind.patch +net-enetc-fix-the-off-by-one-issue-in-enetc_map_tx_buffs.patch +net-enetc-keep-track-of-correct-tx-bd-count-in-enetc_map_tx_tso_buffs.patch +net-enetc-update-udp-checksum-when-updating-origintimestamp-field.patch +net-enetc-correct-the-xdp_tx-statistics.patch +net-enetc-fix-the-off-by-one-issue-in-enetc_map_tx_tso_buffs.patch +phy-tegra-xusb-reset-vbus-id-override.patch +phy-exynos5-usbdrd-fix-mpll_multiplier-and-ssc_refclksel-masks-in-refclk.patch +mptcp-always-handle-address-removal-under-msk-socket-lock.patch +mptcp-reset-when-mptcp-opts-are-dropped-after-join.patch +vmlinux.lds-ensure-that-const-vars-with-relocations-are-mapped-r-o.patch +rcuref-plug-slowpath-race-in-rcuref_put.patch +sched-core-prevent-rescheduling-when-interrupts-are-disabled.patch +scsi-ufs-core-bsg-fix-crash-when-arpmb-command-fails.patch +rseq-selftests-fix-riscv-rseq_offset_deref_addv-inline-asm.patch +riscv-futex-sign-extend-compare-value-in-atomic-cmpxchg.patch +riscv-signal-fix-signal-frame-size.patch diff --git a/queue-6.6/tracing-fix-bad-hist-from-corrupting-named_triggers-list.patch b/queue-6.6/tracing-fix-bad-hist-from-corrupting-named_triggers-list.patch new file mode 100644 index 0000000000..036ef095c8 --- /dev/null +++ b/queue-6.6/tracing-fix-bad-hist-from-corrupting-named_triggers-list.patch @@ -0,0 +1,137 @@ +From 6f86bdeab633a56d5c6dccf1a2c5989b6a5e323e Mon Sep 17 00:00:00 2001 +From: Steven Rostedt +Date: Thu, 27 Feb 2025 16:39:44 -0500 +Subject: tracing: Fix bad hist from corrupting named_triggers list + +From: Steven Rostedt + +commit 6f86bdeab633a56d5c6dccf1a2c5989b6a5e323e upstream. + +The following commands causes a crash: + + ~# cd /sys/kernel/tracing/events/rcu/rcu_callback + ~# echo 'hist:name=bad:keys=common_pid:onmax(bogus).save(common_pid)' > trigger + bash: echo: write error: Invalid argument + ~# echo 'hist:name=bad:keys=common_pid' > trigger + +Because the following occurs: + +event_trigger_write() { + trigger_process_regex() { + event_hist_trigger_parse() { + + data = event_trigger_alloc(..); + + event_trigger_register(.., data) { + cmd_ops->reg(.., data, ..) [hist_register_trigger()] { + data->ops->init() [event_hist_trigger_init()] { + save_named_trigger(name, data) { + list_add(&data->named_list, &named_triggers); + } + } + } + } + + ret = create_actions(); (return -EINVAL) + if (ret) + goto out_unreg; +[..] + ret = hist_trigger_enable(data, ...) { + list_add_tail_rcu(&data->list, &file->triggers); <<<---- SKIPPED!!! (this is important!) +[..] + out_unreg: + event_hist_unregister(.., data) { + cmd_ops->unreg(.., data, ..) [hist_unregister_trigger()] { + list_for_each_entry(iter, &file->triggers, list) { + if (!hist_trigger_match(data, iter, named_data, false)) <- never matches + continue; + [..] + test = iter; + } + if (test && test->ops->free) <<<-- test is NULL + + test->ops->free(test) [event_hist_trigger_free()] { + [..] + if (data->name) + del_named_trigger(data) { + list_del(&data->named_list); <<<<-- NEVER gets removed! + } + } + } + } + + [..] + kfree(data); <<<-- frees item but it is still on list + +The next time a hist with name is registered, it causes an u-a-f bug and +the kernel can crash. + +Move the code around such that if event_trigger_register() succeeds, the +next thing called is hist_trigger_enable() which adds it to the list. + +A bunch of actions is called if get_named_trigger_data() returns false. +But that doesn't need to be called after event_trigger_register(), so it +can be moved up, allowing event_trigger_register() to be called just +before hist_trigger_enable() keeping them together and allowing the +file->triggers to be properly populated. + +Cc: stable@vger.kernel.org +Cc: Masami Hiramatsu +Cc: Mathieu Desnoyers +Link: https://lore.kernel.org/20250227163944.1c37f85f@gandalf.local.home +Fixes: 067fe038e70f6 ("tracing: Add variable reference handling to hist triggers") +Reported-by: Tomas Glozar +Tested-by: Tomas Glozar +Reviewed-by: Tom Zanussi +Closes: https://lore.kernel.org/all/CAP4=nvTsxjckSBTz=Oe_UYh8keD9_sZC4i++4h72mJLic4_W4A@mail.gmail.com/ +Signed-off-by: Steven Rostedt (Google) +Signed-off-by: Greg Kroah-Hartman +--- + kernel/trace/trace_events_hist.c | 30 +++++++++++++++--------------- + 1 file changed, 15 insertions(+), 15 deletions(-) + +--- a/kernel/trace/trace_events_hist.c ++++ b/kernel/trace/trace_events_hist.c +@@ -6660,27 +6660,27 @@ static int event_hist_trigger_parse(stru + if (existing_hist_update_only(glob, trigger_data, file)) + goto out_free; + +- ret = event_trigger_register(cmd_ops, file, glob, trigger_data); +- if (ret < 0) +- goto out_free; ++ if (!get_named_trigger_data(trigger_data)) { + +- if (get_named_trigger_data(trigger_data)) +- goto enable; ++ ret = create_actions(hist_data); ++ if (ret) ++ goto out_free; + +- ret = create_actions(hist_data); +- if (ret) +- goto out_unreg; ++ if (has_hist_vars(hist_data) || hist_data->n_var_refs) { ++ ret = save_hist_vars(hist_data); ++ if (ret) ++ goto out_free; ++ } + +- if (has_hist_vars(hist_data) || hist_data->n_var_refs) { +- ret = save_hist_vars(hist_data); ++ ret = tracing_map_init(hist_data->map); + if (ret) +- goto out_unreg; ++ goto out_free; + } + +- ret = tracing_map_init(hist_data->map); +- if (ret) +- goto out_unreg; +-enable: ++ ret = event_trigger_register(cmd_ops, file, glob, trigger_data); ++ if (ret < 0) ++ goto out_free; ++ + ret = hist_trigger_enable(trigger_data, file); + if (ret) + goto out_unreg; diff --git a/queue-6.6/usbnet-gl620a-fix-endpoint-checking-in-genelink_bind.patch b/queue-6.6/usbnet-gl620a-fix-endpoint-checking-in-genelink_bind.patch new file mode 100644 index 0000000000..cc3da86cad --- /dev/null +++ b/queue-6.6/usbnet-gl620a-fix-endpoint-checking-in-genelink_bind.patch @@ -0,0 +1,93 @@ +From 1cf9631d836b289bd5490776551961c883ae8a4f Mon Sep 17 00:00:00 2001 +From: Nikita Zhandarovich +Date: Mon, 24 Feb 2025 20:29:17 +0300 +Subject: usbnet: gl620a: fix endpoint checking in genelink_bind() + +From: Nikita Zhandarovich + +commit 1cf9631d836b289bd5490776551961c883ae8a4f upstream. + +Syzbot reports [1] a warning in usb_submit_urb() triggered by +inconsistencies between expected and actually present endpoints +in gl620a driver. Since genelink_bind() does not properly +verify whether specified eps are in fact provided by the device, +in this case, an artificially manufactured one, one may get a +mismatch. + +Fix the issue by resorting to a usbnet utility function +usbnet_get_endpoints(), usually reserved for this very problem. +Check for endpoints and return early before proceeding further if +any are missing. + +[1] Syzbot report: +usb 5-1: Manufacturer: syz +usb 5-1: SerialNumber: syz +usb 5-1: config 0 descriptor?? +gl620a 5-1:0.23 usb0: register 'gl620a' at usb-dummy_hcd.0-1, ... +------------[ cut here ]------------ +usb 5-1: BOGUS urb xfer, pipe 3 != type 1 +WARNING: CPU: 2 PID: 1841 at drivers/usb/core/urb.c:503 usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503 +Modules linked in: +CPU: 2 UID: 0 PID: 1841 Comm: kworker/2:2 Not tainted 6.12.0-syzkaller-07834-g06afb0f36106 #0 +Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 +Workqueue: mld mld_ifc_work +RIP: 0010:usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503 +... +Call Trace: + + usbnet_start_xmit+0x6be/0x2780 drivers/net/usb/usbnet.c:1467 + __netdev_start_xmit include/linux/netdevice.h:5002 [inline] + netdev_start_xmit include/linux/netdevice.h:5011 [inline] + xmit_one net/core/dev.c:3590 [inline] + dev_hard_start_xmit+0x9a/0x7b0 net/core/dev.c:3606 + sch_direct_xmit+0x1ae/0xc30 net/sched/sch_generic.c:343 + __dev_xmit_skb net/core/dev.c:3827 [inline] + __dev_queue_xmit+0x13d4/0x43e0 net/core/dev.c:4400 + dev_queue_xmit include/linux/netdevice.h:3168 [inline] + neigh_resolve_output net/core/neighbour.c:1514 [inline] + neigh_resolve_output+0x5bc/0x950 net/core/neighbour.c:1494 + neigh_output include/net/neighbour.h:539 [inline] + ip6_finish_output2+0xb1b/0x2070 net/ipv6/ip6_output.c:141 + __ip6_finish_output net/ipv6/ip6_output.c:215 [inline] + ip6_finish_output+0x3f9/0x1360 net/ipv6/ip6_output.c:226 + NF_HOOK_COND include/linux/netfilter.h:303 [inline] + ip6_output+0x1f8/0x540 net/ipv6/ip6_output.c:247 + dst_output include/net/dst.h:450 [inline] + NF_HOOK include/linux/netfilter.h:314 [inline] + NF_HOOK include/linux/netfilter.h:308 [inline] + mld_sendpack+0x9f0/0x11d0 net/ipv6/mcast.c:1819 + mld_send_cr net/ipv6/mcast.c:2120 [inline] + mld_ifc_work+0x740/0xca0 net/ipv6/mcast.c:2651 + process_one_work+0x9c5/0x1ba0 kernel/workqueue.c:3229 + process_scheduled_works kernel/workqueue.c:3310 [inline] + worker_thread+0x6c8/0xf00 kernel/workqueue.c:3391 + kthread+0x2c1/0x3a0 kernel/kthread.c:389 + ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 + ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 + + +Reported-by: syzbot+d693c07c6f647e0388d3@syzkaller.appspotmail.com +Closes: https://syzkaller.appspot.com/bug?extid=d693c07c6f647e0388d3 +Fixes: 47ee3051c856 ("[PATCH] USB: usbnet (5/9) module for genesys gl620a cables") +Cc: stable@vger.kernel.org +Signed-off-by: Nikita Zhandarovich +Link: https://patch.msgid.link/20250224172919.1220522-1-n.zhandarovich@fintech.ru +Signed-off-by: Paolo Abeni +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/usb/gl620a.c | 4 +--- + 1 file changed, 1 insertion(+), 3 deletions(-) + +--- a/drivers/net/usb/gl620a.c ++++ b/drivers/net/usb/gl620a.c +@@ -179,9 +179,7 @@ static int genelink_bind(struct usbnet * + { + dev->hard_mtu = GL_RCV_BUF_SIZE; + dev->net->hard_header_len += 4; +- dev->in = usb_rcvbulkpipe(dev->udev, dev->driver_info->in); +- dev->out = usb_sndbulkpipe(dev->udev, dev->driver_info->out); +- return 0; ++ return usbnet_get_endpoints(dev, intf); + } + + static const struct driver_info genelink_info = { diff --git a/queue-6.6/vmlinux.lds-ensure-that-const-vars-with-relocations-are-mapped-r-o.patch b/queue-6.6/vmlinux.lds-ensure-that-const-vars-with-relocations-are-mapped-r-o.patch new file mode 100644 index 0000000000..db72928f35 --- /dev/null +++ b/queue-6.6/vmlinux.lds-ensure-that-const-vars-with-relocations-are-mapped-r-o.patch @@ -0,0 +1,52 @@ +From 68f3ea7ee199ef77551e090dfef5a49046ea8443 Mon Sep 17 00:00:00 2001 +From: Ard Biesheuvel +Date: Fri, 21 Feb 2025 14:57:06 +0100 +Subject: vmlinux.lds: Ensure that const vars with relocations are mapped R/O + +From: Ard Biesheuvel + +commit 68f3ea7ee199ef77551e090dfef5a49046ea8443 upstream. + +In the kernel, there are architectures (x86, arm64) that perform +boot-time relocation (for KASLR) without relying on PIE codegen. In this +case, all const global objects are emitted into .rodata, including const +objects with fields that will be fixed up by the boot-time relocation +code. This implies that .rodata (and .text in some cases) need to be +writable at boot, but they will usually be mapped read-only as soon as +the boot completes. + +When using PIE codegen, the compiler will emit const global objects into +.data.rel.ro rather than .rodata if the object contains fields that need +such fixups at boot-time. This permits the linker to annotate such +regions as requiring read-write access only at load time, but not at +execution time (in user space), while keeping .rodata truly const (in +user space, this is important for reducing the CoW footprint of dynamic +executables). + +This distinction does not matter for the kernel, but it does imply that +const data will end up in writable memory if the .data.rel.ro sections +are not treated in a special way, as they will end up in the writable +.data segment by default. + +So emit .data.rel.ro into the .rodata segment. + +Cc: stable@vger.kernel.org +Signed-off-by: Ard Biesheuvel +Link: https://lore.kernel.org/r/20250221135704.431269-5-ardb+git@google.com +Signed-off-by: Josh Poimboeuf +Signed-off-by: Greg Kroah-Hartman +--- + include/asm-generic/vmlinux.lds.h | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/include/asm-generic/vmlinux.lds.h ++++ b/include/asm-generic/vmlinux.lds.h +@@ -445,7 +445,7 @@ + . = ALIGN((align)); \ + .rodata : AT(ADDR(.rodata) - LOAD_OFFSET) { \ + __start_rodata = .; \ +- *(.rodata) *(.rodata.*) \ ++ *(.rodata) *(.rodata.*) *(.data.rel.ro*) \ + SCHED_DATA \ + RO_AFTER_INIT_DATA /* Read only after init */ \ + . = ALIGN(8); \