--- /dev/null
+From 9af3b4f2d879da01192d6168e6c651e7fb5b652d Mon Sep 17 00:00:00 2001
+From: Dmitry Panchenko <dmitry@d-systems.ee>
+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 <dmitry@d-systems.ee>
+
+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 <dmitry@d-systems.ee>
+Cc: <stable@vger.kernel.org>
+Link: https://patch.msgid.link/20250220161540.3624660-1-dmitry@d-systems.ee
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/usb/quirks.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/sound/usb/quirks.c
++++ b/sound/usb/quirks.c
+@@ -1502,6 +1502,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;
--- /dev/null
+From 4de141b8b1b7991b607f77e5f4580e1c67c24717 Mon Sep 17 00:00:00 2001
+From: Roman Li <Roman.Li@amd.com>
+Date: Wed, 12 Feb 2025 14:49:36 -0500
+Subject: drm/amd/display: Fix HPD after gpu reset
+
+From: Roman Li <Roman.Li@amd.com>
+
+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 <mario.limonciello@amd.com>
+Cc: Alex Deucher <alexander.deucher@amd.com>
+Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
+Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com>
+Signed-off-by: Roman Li <Roman.Li@amd.com>
+Signed-off-by: Zaeem Mohamed <zaeem.mohamed@amd.com>
+Tested-by: Daniel Wheeler <daniel.wheeler@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+(cherry picked from commit f3dde2ff7fcaacd77884502e8f572f2328e9c745)
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+@@ -885,6 +885,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) {
+@@ -906,6 +907,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);
++ }
+ }
+
+ /**
+@@ -921,6 +928,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) {
+@@ -937,4 +945,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);
++ }
+ }
--- /dev/null
+From a1a7eb89ca0b89dc1c326eeee2596f263291aca3 Mon Sep 17 00:00:00 2001
+From: Nikolay Kuratov <kniv@yandex-team.ru>
+Date: Thu, 6 Feb 2025 12:01:56 +0300
+Subject: ftrace: Avoid potential division by zero in function_stat_show()
+
+From: Nikolay Kuratov <kniv@yandex-team.ru>
+
+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 <wenyang@linux.alibaba.com>
+Cc: Mark Rutland <mark.rutland@arm.com>
+Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
+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 <kniv@yandex-team.ru>
+Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/ftrace.c | 27 ++++++++++++---------------
+ 1 file changed, 12 insertions(+), 15 deletions(-)
+
+--- a/kernel/trace/ftrace.c
++++ b/kernel/trace/ftrace.c
+@@ -510,6 +510,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);
+
+@@ -531,23 +532,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);
--- /dev/null
+From dd1998e243f5fa25d348a384ba0b6c84d980f2b2 Mon Sep 17 00:00:00 2001
+From: Tyrone Ting <kfting@nuvoton.com>
+Date: Thu, 20 Feb 2025 12:00:29 +0800
+Subject: i2c: npcm: disable interrupt enable bit before devm_request_irq
+
+From: Tyrone Ting <kfting@nuvoton.com>
+
+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 <kfting@nuvoton.com>
+Cc: <stable@vger.kernel.org> # v5.8+
+Reviewed-by: Tali Perry <tali.perry1@gmail.com>
+Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
+Link: https://lore.kernel.org/r/20250220040029.27596-2-kfting@nuvoton.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+@@ -2305,6 +2305,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)
--- /dev/null
+From 982caaa1150479f022003390cd72a1941663d211 Mon Sep 17 00:00:00 2001
+From: Sean Christopherson <seanjc@google.com>
+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 <seanjc@google.com>
+
+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 <seanjc@google.com>
+Message-ID: <20250224235542.2562848-3-seanjc@google.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+@@ -4713,6 +4713,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;
+ }
+
--- /dev/null
+From f865c24bc55158313d5779fc81116023a6940ca3 Mon Sep 17 00:00:00 2001
+From: Paolo Abeni <pabeni@redhat.com>
+Date: Mon, 24 Feb 2025 19:11:50 +0100
+Subject: mptcp: always handle address removal under msk socket lock
+
+From: Paolo Abeni <pabeni@redhat.com>
+
+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:
+ <TASK>
+ 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 <pabeni@redhat.com>
+Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+Link: https://patch.msgid.link/20250224-net-mptcp-misc-fixes-v1-1-f550f636b435@kernel.org
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/mptcp/pm_netlink.c | 6 ------
+ 1 file changed, 6 deletions(-)
+
+--- a/net/mptcp/pm_netlink.c
++++ b/net/mptcp/pm_netlink.c
+@@ -1406,11 +1406,6 @@ static int mptcp_nl_remove_subflow_and_s
+ struct sock *sk = (struct sock *)msk;
+ bool remove_subflow;
+
+- 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);
+@@ -1418,7 +1413,6 @@ static int mptcp_nl_remove_subflow_and_s
+ mptcp_pm_remove_subflow(msk, &list);
+ release_sock(sk);
+
+-next:
+ sock_put(sk);
+ cond_resched();
+ }
--- /dev/null
+From 432a2cb3ee97a7c6ea578888fe81baad035b9307 Mon Sep 17 00:00:00 2001
+From: Wei Fang <wei.fang@nxp.com>
+Date: Mon, 24 Feb 2025 19:12:46 +0800
+Subject: net: enetc: correct the xdp_tx statistics
+
+From: Wei Fang <wei.fang@nxp.com>
+
+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 <wei.fang@nxp.com>
+Reviewed-by: Ioana Ciornei <ioana.ciornei@nxp.com>
+Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
+Link: https://patch.msgid.link/20250224111251.1061098-4-wei.fang@nxp.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+@@ -1343,7 +1343,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
--- /dev/null
+From 39ab773e4c120f7f98d759415ccc2aca706bbc10 Mon Sep 17 00:00:00 2001
+From: Wei Fang <wei.fang@nxp.com>
+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 <wei.fang@nxp.com>
+
+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 <vladimir.oltean@nxp.com>
+Suggested-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
+Signed-off-by: Wei Fang <wei.fang@nxp.com>
+Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
+Reviewed-by: Claudiu Manoil <claudiu.manoil@nxp.com>
+Link: https://patch.msgid.link/20250224111251.1061098-2-wei.fang@nxp.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+@@ -121,6 +121,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;
+@@ -303,13 +321,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;
+ }
--- /dev/null
+From bbcbc906ab7b5834c1219cd17a38d78dba904aa0 Mon Sep 17 00:00:00 2001
+From: Wei Fang <wei.fang@nxp.com>
+Date: Mon, 24 Feb 2025 19:12:48 +0800
+Subject: net: enetc: update UDP checksum when updating originTimestamp field
+
+From: Wei Fang <wei.fang@nxp.com>
+
+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 <wei.fang@nxp.com>
+Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
+Tested-by: Vladimir Oltean <vladimir.oltean@nxp.com>
+Link: https://patch.msgid.link/20250224111251.1061098-6-wei.fang@nxp.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+@@ -228,9 +228,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);
+@@ -244,13 +246,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;
--- /dev/null
+From 0d39844150546fa1415127c5fbae26db64070dd3 Mon Sep 17 00:00:00 2001
+From: Kan Liang <kan.liang@linux.intel.com>
+Date: Fri, 17 Jan 2025 07:19:12 -0800
+Subject: perf/core: Fix low freq setting via IOC_PERIOD
+
+From: Kan Liang <kan.liang@linux.intel.com>
+
+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 <kan.liang@linux.intel.com>
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Reviewed-by: Ravi Bangoria <ravi.bangoria@amd.com>
+Cc: Peter Zijlstra <peterz@infradead.org>
+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 <gregkh@linuxfoundation.org>
+---
+ kernel/events/core.c | 17 +++++++++--------
+ 1 file changed, 9 insertions(+), 8 deletions(-)
+
+--- a/kernel/events/core.c
++++ b/kernel/events/core.c
+@@ -5773,14 +5773,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);
+
--- /dev/null
+From e2158c953c973adb49383ddea2504faf08d375b7 Mon Sep 17 00:00:00 2001
+From: Kaustabh Chakraborty <kauschluss@disroot.org>
+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 <kauschluss@disroot.org>
+
+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 <kauschluss@disroot.org>
+Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Reviewed-by: Anand Moon <linux.amoon@gmail.com>
+Link: https://lore.kernel.org/r/20250209-exynos5-usbdrd-masks-v1-1-4f7f83f323d7@disroot.org
+Signed-off-by: Vinod Koul <vkoul@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+@@ -288,9 +288,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 |
+@@ -332,9 +332,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;
--- /dev/null
+From 55f1a5f7c97c3c92ba469e16991a09274410ceb7 Mon Sep 17 00:00:00 2001
+From: BH Hsieh <bhsieh@nvidia.com>
+Date: Wed, 22 Jan 2025 18:59:43 +0800
+Subject: phy: tegra: xusb: reset VBUS & ID OVERRIDE
+
+From: BH Hsieh <bhsieh@nvidia.com>
+
+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 <bhsieh@nvidia.com>
+Signed-off-by: Henry Lin <henryl@nvidia.com>
+Link: https://lore.kernel.org/r/20250122105943.8057-1-henryl@nvidia.com
+Signed-off-by: Vinod Koul <vkoul@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+@@ -897,6 +897,7 @@ static int tegra186_utmi_phy_exit(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) {
+@@ -904,6 +905,16 @@ static int tegra186_utmi_phy_exit(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_disable(port->supply);
+ if (err) {
--- /dev/null
+From 82c387ef7568c0d96a918a5a78d9cad6256cfa15 Mon Sep 17 00:00:00 2001
+From: Thomas Gleixner <tglx@linutronix.de>
+Date: Mon, 16 Dec 2024 14:20:56 +0100
+Subject: sched/core: Prevent rescheduling when interrupts are disabled
+
+From: Thomas Gleixner <tglx@linutronix.de>
+
+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): [<ffffffffa8281b8e>] __up_console_sem+0x7e/0x90
+ hardirqs last disabled at (15580): [<ffffffffa8281b73>] __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 <dwmw@amazon.co.uk>
+Suggested-by: Peter Zijlstra <peterz@infradead.org>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Tested-by: David Woodhouse <dwmw@amazon.co.uk>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: stable@vger.kernel.org
+Closes: https://lore.kernel.org/all/7717fe2ac0ce5f0a2c43fdab8b11f4483d54a2a4.camel@infradead.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/sched/core.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/kernel/sched/core.c
++++ b/kernel/sched/core.c
+@@ -8247,7 +8247,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;
+ }
net-ipv6-rpl_iptunnel-mitigate-2-realloc-issue.patch
net-ipv6-fix-dst-ref-loop-on-input-in-rpl-lwt.patch
x86-cpu-fix-warm-boot-hang-regression-on-amd-sc1100-.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
+kvm-nvmx-process-events-on-nested-vm-exit-if-injectable-irq-or-nmi-is-pending.patch
+perf-core-fix-low-freq-setting-via-ioc_period.patch
+drm-amd-display-fix-hpd-after-gpu-reset.patch
+i2c-npcm-disable-interrupt-enable-bit-before-devm_request_irq.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-update-udp-checksum-when-updating-origintimestamp-field.patch
+net-enetc-correct-the-xdp_tx-statistics.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
+vmlinux.lds-ensure-that-const-vars-with-relocations-are-mapped-r-o.patch
+sched-core-prevent-rescheduling-when-interrupts-are-disabled.patch
--- /dev/null
+From 1cf9631d836b289bd5490776551961c883ae8a4f Mon Sep 17 00:00:00 2001
+From: Nikita Zhandarovich <n.zhandarovich@fintech.ru>
+Date: Mon, 24 Feb 2025 20:29:17 +0300
+Subject: usbnet: gl620a: fix endpoint checking in genelink_bind()
+
+From: Nikita Zhandarovich <n.zhandarovich@fintech.ru>
+
+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:
+ <TASK>
+ 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
+ </TASK>
+
+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 <n.zhandarovich@fintech.ru>
+Link: https://patch.msgid.link/20250224172919.1220522-1-n.zhandarovich@fintech.ru
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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 = {
--- /dev/null
+From 68f3ea7ee199ef77551e090dfef5a49046ea8443 Mon Sep 17 00:00:00 2001
+From: Ard Biesheuvel <ardb@kernel.org>
+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 <ardb@kernel.org>
+
+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 <ardb@kernel.org>
+Link: https://lore.kernel.org/r/20250221135704.431269-5-ardb+git@google.com
+Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+@@ -429,7 +429,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); \
projects / thirdparty / kernel / stable-queue.git / commitdiff
