user/sven/linux.git, branch v6.12.41

Linux 6.12.41

2025-08-01T08:48:47Z

Link: https://lore.kernel.org/r/20250730093233.592541778@linuxfoundation.org Tested-by: Jon Hunter Tested-by: Salvatore Bonaccorso Tested-by: Mark Brown Tested-by: Brett A C Sheffield Tested-by: Peter Schneider Tested-by: Shuah Khan Tested-by: Harshit Mogalapalli Tested-by: Ron Economos Tested-by: Linux Kernel Functional Testing Tested-by: Brett Mastbergen Tested-by: Miguel Ojeda Tested-by: Hardik Garg Signed-off-by: Greg Kroah-Hartman

mm: khugepaged: fix call hpage_collapse_scan_file() for anonymous vma

2025-08-01T08:48:47Z

commit f1897f2f08b28ae59476d8b73374b08f856973af upstream. syzkaller reported such a BUG_ON(): ------------[ cut here ]------------ kernel BUG at mm/khugepaged.c:1835! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP ... CPU: 6 UID: 0 PID: 8009 Comm: syz.15.106 Kdump: loaded Tainted: G W 6.13.0-rc6 #22 Tainted: [W]=WARN Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 pstate: 00400005 (nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : collapse_file+0xa44/0x1400 lr : collapse_file+0x88/0x1400 sp : ffff80008afe3a60 ... Call trace: collapse_file+0xa44/0x1400 (P) hpage_collapse_scan_file+0x278/0x400 madvise_collapse+0x1bc/0x678 madvise_vma_behavior+0x32c/0x448 madvise_walk_vmas.constprop.0+0xbc/0x140 do_madvise.part.0+0xdc/0x2c8 __arm64_sys_madvise+0x68/0x88 invoke_syscall+0x50/0x120 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x34/0x128 el0t_64_sync_handler+0xc8/0xd0 el0t_64_sync+0x190/0x198 This indicates that the pgoff is unaligned. After analysis, I confirm the vma is mapped to /dev/zero. Such a vma certainly has vm_file, but it is set to anonymous by mmap_zero(). So even if it's mmapped by 2m-unaligned, it can pass the check in thp_vma_allowable_order() as it is an anonymous-mmap, but then be collapsed as a file-mmap. It seems the problem has existed for a long time, but actually, since we have khugepaged_max_ptes_none check before, we will skip collapse it as it is /dev/zero and so has no present page. But commit d8ea7cc8547c limit the check for only khugepaged, so the BUG_ON() can be triggered by madvise_collapse(). Add vma_is_anonymous() check to make such vma be processed by hpage_collapse_scan_pmd(). Link: https://lkml.kernel.org/r/20250111034511.2223353-1-liushixin2@huawei.com Fixes: d8ea7cc8547c ("mm/khugepaged: add flag to predicate khugepaged-only behavior") Signed-off-by: Liu Shixin Reviewed-by: Yang Shi Acked-by: David Hildenbrand Cc: Chengming Zhou Cc: Johannes Weiner Cc: Kefeng Wang Cc: Mattew Wilcox Cc: Muchun Song Cc: Nanyong Sun Cc: Qi Zheng Signed-off-by: Andrew Morton [acsjakub: backport, clean apply] Signed-off-by: Jakub Acs Signed-off-by: Greg Kroah-Hartman

KVM: x86: Free vCPUs before freeing VM state

2025-08-01T08:48:47Z

commit 17bcd714426386fda741a4bccd96a2870179344b upstream. Free vCPUs before freeing any VM state, as both SVM and VMX may access VM state when "freeing" a vCPU that is currently "in" L2, i.e. that needs to be kicked out of nested guest mode. Commit 6fcee03df6a1 ("KVM: x86: avoid loading a vCPU after .vm_destroy was called") partially fixed the issue, but for unknown reasons only moved the MMU unloading before VM destruction. Complete the change, and free all vCPU state prior to destroying VM state, as nVMX accesses even more state than nSVM. In addition to the AVIC, KVM can hit a use-after-free on MSR filters: kvm_msr_allowed+0x4c/0xd0 __kvm_set_msr+0x12d/0x1e0 kvm_set_msr+0x19/0x40 load_vmcs12_host_state+0x2d8/0x6e0 [kvm_intel] nested_vmx_vmexit+0x715/0xbd0 [kvm_intel] nested_vmx_free_vcpu+0x33/0x50 [kvm_intel] vmx_free_vcpu+0x54/0xc0 [kvm_intel] kvm_arch_vcpu_destroy+0x28/0xf0 kvm_vcpu_destroy+0x12/0x50 kvm_arch_destroy_vm+0x12c/0x1c0 kvm_put_kvm+0x263/0x3c0 kvm_vm_release+0x21/0x30 and an upcoming fix to process injectable interrupts on nested VM-Exit will access the PIC: BUG: kernel NULL pointer dereference, address: 0000000000000090 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page CPU: 23 UID: 1000 PID: 2658 Comm: kvm-nx-lpage-re RIP: 0010:kvm_cpu_has_extint+0x2f/0x60 [kvm] Call Trace: kvm_cpu_has_injectable_intr+0xe/0x60 [kvm] nested_vmx_vmexit+0x2d7/0xdf0 [kvm_intel] nested_vmx_free_vcpu+0x40/0x50 [kvm_intel] vmx_vcpu_free+0x2d/0x80 [kvm_intel] kvm_arch_vcpu_destroy+0x2d/0x130 [kvm] kvm_destroy_vcpus+0x8a/0x100 [kvm] kvm_arch_destroy_vm+0xa7/0x1d0 [kvm] kvm_destroy_vm+0x172/0x300 [kvm] kvm_vcpu_release+0x31/0x50 [kvm] Inarguably, both nSVM and nVMX need to be fixed, but punt on those cleanups for the moment. Conceptually, vCPUs should be freed before VM state. Assets like the I/O APIC and PIC _must_ be allocated before vCPUs are created, so it stands to reason that they must be freed _after_ vCPUs are destroyed. Reported-by: Aaron Lewis Closes: https://lore.kernel.org/all/20240703175618.2304869-2-aaronlewis@google.com Cc: Jim Mattson Cc: Yan Zhao Cc: Rick P Edgecombe Cc: Kai Huang Cc: Isaku Yamahata Signed-off-by: Sean Christopherson Message-ID: <20250224235542.2562848-2-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Kevin Cheng Signed-off-by: Greg Kroah-Hartman

Revert "drm/xe/forcewake: Add a helper xe_force_wake_ref_has_domain()"

2025-08-01T08:48:47Z

This reverts commit deb05f8431f31e08fd6ab99a56069fc98014dbec. The helper function introduced in the reverted commit is for handling the "refcounted domain mask" introduced in commit a7ddcea1f5ac ("drm/xe: Error handling in xe_force_wake_get()"). Since that API change only exists in 6.13 and later, this helper is unnecessary in 6.12 stable kernel. Cc: Michal Wajdeczko Cc: Badal Nilawar Cc: Himal Prasad Ghimiray Acked-by: Rodrigo Vivi Signed-off-by: Tomita Moeko Signed-off-by: Greg Kroah-Hartman

Revert "drm/xe/devcoredump: Update handling of xe_force_wake_get return"

2025-08-01T08:48:47Z

This reverts commit 9ffd6ec2de08ef4ac5f17f6131d1db57613493f9. The reverted commit updated the handling of xe_force_wake_get to match the new "return refcounted domain mask" semantics introduced in commit a7ddcea1f5ac ("drm/xe: Error handling in xe_force_wake_get()"). However, that API change only exists in 6.13 and later. In 6.12 stable kernel, xe_force_wake_get still returns a status code. The update incorrectly treats the return value as a mask, causing the return value of 0 to be misinterpreted as an error Cc: Rodrigo Vivi Cc: Lucas De Marchi Cc: Himal Prasad Ghimiray Cc: Nirmoy Das Cc: Badal Nilawar Acked-by: Rodrigo Vivi Signed-off-by: Tomita Moeko Signed-off-by: Greg Kroah-Hartman

Revert "drm/xe/tests/mocs: Update xe_force_wake_get() return handling"

2025-08-01T08:48:47Z

This reverts commit 95a75ed2b005447f96fbd4ac61758ccda44069d1. The reverted commit updated the handling of xe_force_wake_get to match the new "return refcounted domain mask" semantics introduced in commit a7ddcea1f5ac ("drm/xe: Error handling in xe_force_wake_get()"). However, that API change only exists in 6.13 and later. In 6.12 stable kernel, xe_force_wake_get still returns a status code. The update incorrectly treats the return value as a mask, causing the return value of 0 to be misinterpreted as an error. Cc: Rodrigo Vivi Cc: Lucas De Marchi Cc: Himal Prasad Ghimiray Cc: Nirmoy Das Cc: Badal Nilawar Acked-by: Rodrigo Vivi Signed-off-by: Tomita Moeko Signed-off-by: Greg Kroah-Hartman

Revert "drm/xe/gt: Update handling of xe_force_wake_get return"

2025-08-01T08:48:47Z

This reverts commit d42b44736ea29fa6d0c3cb9c75569314134b7732. The reverted commit updated the handling of xe_force_wake_get to match the new "return refcounted domain mask" semantics introduced in commit a7ddcea1f5ac ("drm/xe: Error handling in xe_force_wake_get()"). However, that API change only exists in 6.13 and later. In 6.12 stable kernel, xe_force_wake_get still returns a status code. The update incorrectly treats the return value as a mask, causing the return value of 0 to be misinterpreted as an error. As a result, the driver probe fails with -ETIMEDOUT in xe_pci_probe -> xe_device_probe -> xe_gt_init_hwconfig -> xe_force_wake_get. [ 1254.323172] xe 0000:00:02.0: [drm] Found ALDERLAKE_P (device ID 46a6) display version 13.00 stepping D0 [ 1254.323175] xe 0000:00:02.0: [drm:xe_pci_probe [xe]] ALDERLAKE_P 46a6:000c dgfx:0 gfx:Xe_LP (12.00) media:Xe_M (12.00) display:yes dma_m_s:39 tc:1 gscfi:0 cscfi:0 [ 1254.323275] xe 0000:00:02.0: [drm:xe_pci_probe [xe]] Stepping = (G:C0, M:C0, B:**) [ 1254.323328] xe 0000:00:02.0: [drm:xe_pci_probe [xe]] SR-IOV support: no (mode: none) [ 1254.323379] xe 0000:00:02.0: [drm:intel_pch_type [xe]] Found Alder Lake PCH [ 1254.323475] xe 0000:00:02.0: probe with driver xe failed with error -110 Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/5373 Cc: Badal Nilawar Cc: Matthew Brost Cc: Rodrigo Vivi Cc: Lucas De Marchi Cc: Himal Prasad Ghimiray Cc: Nirmoy Das Acked-by: Rodrigo Vivi Signed-off-by: Tomita Moeko Signed-off-by: Greg Kroah-Hartman

drm/i915/dp: Fix 2.7 Gbps DP_LINK_BW value on g4x

2025-08-01T08:48:47Z

commit 9e0c433d0c05fde284025264b89eaa4ad59f0a3e upstream. On g4x we currently use the 96MHz non-SSC refclk, which can't actually generate an exact 2.7 Gbps link rate. In practice we end up with 2.688 Gbps which seems to be close enough to actually work, but link training is currently failing due to miscalculating the DP_LINK_BW value (we calcualte it directly from port_clock which reflects the actual PLL outpout frequency). Ideas how to fix this: - nudge port_clock back up to 270000 during PLL computation/readout - track port_clock and the nominal link rate separately so they might differ a bit - switch to the 100MHz refclk, but that one should be SSC so perhaps not something we want While we ponder about a better solution apply some band aid to the immediate issue of miscalculated DP_LINK_BW value. With this I can again use 2.7 Gbps link rate on g4x. Cc: stable@vger.kernel.org Fixes: 665a7b04092c ("drm/i915: Feed the DPLL output freq back into crtc_state") Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20250710201718.25310-2-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak (cherry picked from commit a8b874694db5cae7baaf522756f87acd956e6e66) Signed-off-by: Rodrigo Vivi [ changed display->platform.g4x to IS_G4X(i915) ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

ALSA: hda: Add missing NVIDIA HDA codec IDs

2025-08-01T08:48:47Z

commit e0a911ac86857a73182edde9e50d9b4b949b7f01 upstream. Add codec IDs for several NVIDIA products with HDA controllers to the snd_hda_id_hdmi[] patch table. Signed-off-by: Daniel Dadap Cc: Link: https://patch.msgid.link/aF24rqwMKFWoHu12@ddadap-lakeline.nvidia.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

ALSA: hda/tegra: Add Tegra264 support

2025-08-01T08:48:47Z

commit 1c4193917eb3279788968639f24d72ffeebdec6b upstream. Update HDA driver to support Tegra264 differences from legacy HDA, which includes: clocks/resets, always power on, and hardware-managed FPCI/IPFS initialization. The driver retrieves this chip-specific information from soc_data. Signed-off-by: Mohan Kumar D Signed-off-by: Sheetal Signed-off-by: Takashi Iwai Link: https://patch.msgid.link/20250512064258.1028331-4-sheetal@nvidia.com Stable-dep-of: e0a911ac8685 ("ALSA: hda: Add missing NVIDIA HDA codec IDs") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman