From: Greg Kroah-Hartman Date: Mon, 19 Jan 2026 11:50:02 +0000 (+0100) Subject: 6.12-stable patches X-Git-Tag: v5.15.198~2 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=09a3ee1846d03d340cde6574f61b479f129a7107;p=thirdparty%2Fkernel%2Fstable-queue.git 6.12-stable patches added patches: asoc-codecs-wsa884x-fix-codec-initialisation.patch revert-gfs2-fix-use-of-bio_chain.patch x86-fpu-clear-xstate_bv-in-guest-xsave-state-whenever-xfd-1.patch --- diff --git a/queue-6.12/asoc-codecs-wsa884x-fix-codec-initialisation.patch b/queue-6.12/asoc-codecs-wsa884x-fix-codec-initialisation.patch new file mode 100644 index 0000000000..fc9daf008a --- /dev/null +++ b/queue-6.12/asoc-codecs-wsa884x-fix-codec-initialisation.patch @@ -0,0 +1,54 @@ +From 120f3e6ff76209ee2f62a64e5e7e9d70274df42b Mon Sep 17 00:00:00 2001 +From: Johan Hovold +Date: Fri, 2 Jan 2026 12:14:12 +0100 +Subject: ASoC: codecs: wsa884x: fix codec initialisation + +From: Johan Hovold + +commit 120f3e6ff76209ee2f62a64e5e7e9d70274df42b upstream. + +The soundwire update_status() callback may be called multiple times with +the same ATTACHED status but initialisation should only be done when +transitioning from UNATTACHED to ATTACHED. + +Fix the inverted hw_init flag which was set to false instead of true +after initialisation which defeats its purpose and may result in +repeated unnecessary initialisation. + +Similarly, the initial state of the flag was also inverted so that the +codec would only be initialised and brought out of regmap cache only +mode if its status first transitions to UNATTACHED. + +Fixes: aa21a7d4f68a ("ASoC: codecs: wsa884x: Add WSA884x family of speakers") +Cc: stable@vger.kernel.org # 6.5 +Cc: Krzysztof Kozlowski +Signed-off-by: Johan Hovold +Reviewed-by: Krzysztof Kozlowski +Tested-by: Krzysztof Kozlowski +Reviewed-by: Srinivas Kandagatla +Link: https://patch.msgid.link/20260102111413.9605-4-johan@kernel.org +Signed-off-by: Mark Brown +Signed-off-by: Greg Kroah-Hartman +--- + sound/soc/codecs/wsa884x.c | 3 +-- + 1 file changed, 1 insertion(+), 2 deletions(-) + +--- a/sound/soc/codecs/wsa884x.c ++++ b/sound/soc/codecs/wsa884x.c +@@ -1534,7 +1534,7 @@ static void wsa884x_init(struct wsa884x_ + + wsa884x_set_gain_parameters(wsa884x); + +- wsa884x->hw_init = false; ++ wsa884x->hw_init = true; + } + + static int wsa884x_update_status(struct sdw_slave *slave, +@@ -2110,7 +2110,6 @@ static int wsa884x_probe(struct sdw_slav + + /* Start in cache-only until device is enumerated */ + regcache_cache_only(wsa884x->regmap, true); +- wsa884x->hw_init = true; + + if (IS_REACHABLE(CONFIG_HWMON)) { + struct device *hwmon; diff --git a/queue-6.12/revert-gfs2-fix-use-of-bio_chain.patch b/queue-6.12/revert-gfs2-fix-use-of-bio_chain.patch new file mode 100644 index 0000000000..4a1a5f59ff --- /dev/null +++ b/queue-6.12/revert-gfs2-fix-use-of-bio_chain.patch @@ -0,0 +1,36 @@ +From 469d71512d135907bf5ea0972dfab8c420f57848 Mon Sep 17 00:00:00 2001 +From: Andreas Gruenbacher +Date: Mon, 12 Jan 2026 11:47:35 +0100 +Subject: Revert "gfs2: Fix use of bio_chain" + +From: Andreas Gruenbacher + +commit 469d71512d135907bf5ea0972dfab8c420f57848 upstream. + +This reverts commit 8a157e0a0aa5143b5d94201508c0ca1bb8cfb941. + +That commit incorrectly assumed that the bio_chain() arguments were +swapped in gfs2. However, gfs2 intentionally constructs bio chains so +that the first bio's bi_end_io callback is invoked when all bios in the +chain have completed, unlike bio chains where the last bio's callback is +invoked. + +Fixes: 8a157e0a0aa5 ("gfs2: Fix use of bio_chain") +Cc: stable@vger.kernel.org +Signed-off-by: Andreas Gruenbacher +Signed-off-by: Greg Kroah-Hartman +--- + fs/gfs2/lops.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/fs/gfs2/lops.c ++++ b/fs/gfs2/lops.c +@@ -485,7 +485,7 @@ static struct bio *gfs2_chain_bio(struct + new = bio_alloc(prev->bi_bdev, nr_iovecs, prev->bi_opf, GFP_NOIO); + bio_clone_blkg_association(new, prev); + new->bi_iter.bi_sector = bio_end_sector(prev); +- bio_chain(prev, new); ++ bio_chain(new, prev); + submit_bio(prev); + return new; + } diff --git a/queue-6.12/series b/queue-6.12/series index 25be01389a..4fcac2c749 100644 --- a/queue-6.12/series +++ b/queue-6.12/series @@ -1,2 +1,5 @@ firmware-imx-scu-irq-set-mu_resource_id-before-get-handle.patch efi-cper-fix-cper_bits_to_str-buffer-handling-and-return-value.patch +revert-gfs2-fix-use-of-bio_chain.patch +x86-fpu-clear-xstate_bv-in-guest-xsave-state-whenever-xfd-1.patch +asoc-codecs-wsa884x-fix-codec-initialisation.patch diff --git a/queue-6.12/x86-fpu-clear-xstate_bv-in-guest-xsave-state-whenever-xfd-1.patch b/queue-6.12/x86-fpu-clear-xstate_bv-in-guest-xsave-state-whenever-xfd-1.patch new file mode 100644 index 0000000000..a03f1582e9 --- /dev/null +++ b/queue-6.12/x86-fpu-clear-xstate_bv-in-guest-xsave-state-whenever-xfd-1.patch @@ -0,0 +1,173 @@ +From b45f721775947a84996deb5c661602254ce25ce6 Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +Date: Wed, 31 Dec 2025 16:43:15 +0100 +Subject: x86/fpu: Clear XSTATE_BV[i] in guest XSAVE state whenever XFD[i]=1 + +From: Sean Christopherson + +commit b45f721775947a84996deb5c661602254ce25ce6 upstream. + +When loading guest XSAVE state via KVM_SET_XSAVE, and when updating XFD in +response to a guest WRMSR, clear XFD-disabled features in the saved (or to +be restored) XSTATE_BV to ensure KVM doesn't attempt to load state for +features that are disabled via the guest's XFD. Because the kernel +executes XRSTOR with the guest's XFD, saving XSTATE_BV[i]=1 with XFD[i]=1 +will cause XRSTOR to #NM and panic the kernel. + +E.g. if fpu_update_guest_xfd() sets XFD without clearing XSTATE_BV: + + ------------[ cut here ]------------ + WARNING: arch/x86/kernel/traps.c:1524 at exc_device_not_available+0x101/0x110, CPU#29: amx_test/848 + Modules linked in: kvm_intel kvm irqbypass + CPU: 29 UID: 1000 PID: 848 Comm: amx_test Not tainted 6.19.0-rc2-ffa07f7fd437-x86_amx_nm_xfd_non_init-vm #171 NONE + Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 + RIP: 0010:exc_device_not_available+0x101/0x110 + Call Trace: + + asm_exc_device_not_available+0x1a/0x20 + RIP: 0010:restore_fpregs_from_fpstate+0x36/0x90 + switch_fpu_return+0x4a/0xb0 + kvm_arch_vcpu_ioctl_run+0x1245/0x1e40 [kvm] + kvm_vcpu_ioctl+0x2c3/0x8f0 [kvm] + __x64_sys_ioctl+0x8f/0xd0 + do_syscall_64+0x62/0x940 + entry_SYSCALL_64_after_hwframe+0x4b/0x53 + + ---[ end trace 0000000000000000 ]--- + +This can happen if the guest executes WRMSR(MSR_IA32_XFD) to set XFD[18] = 1, +and a host IRQ triggers kernel_fpu_begin() prior to the vmexit handler's +call to fpu_update_guest_xfd(). + +and if userspace stuffs XSTATE_BV[i]=1 via KVM_SET_XSAVE: + + ------------[ cut here ]------------ + WARNING: arch/x86/kernel/traps.c:1524 at exc_device_not_available+0x101/0x110, CPU#14: amx_test/867 + Modules linked in: kvm_intel kvm irqbypass + CPU: 14 UID: 1000 PID: 867 Comm: amx_test Not tainted 6.19.0-rc2-2dace9faccd6-x86_amx_nm_xfd_non_init-vm #168 NONE + Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 + RIP: 0010:exc_device_not_available+0x101/0x110 + Call Trace: + + asm_exc_device_not_available+0x1a/0x20 + RIP: 0010:restore_fpregs_from_fpstate+0x36/0x90 + fpu_swap_kvm_fpstate+0x6b/0x120 + kvm_load_guest_fpu+0x30/0x80 [kvm] + kvm_arch_vcpu_ioctl_run+0x85/0x1e40 [kvm] + kvm_vcpu_ioctl+0x2c3/0x8f0 [kvm] + __x64_sys_ioctl+0x8f/0xd0 + do_syscall_64+0x62/0x940 + entry_SYSCALL_64_after_hwframe+0x4b/0x53 + + ---[ end trace 0000000000000000 ]--- + +The new behavior is consistent with the AMX architecture. Per Intel's SDM, +XSAVE saves XSTATE_BV as '0' for components that are disabled via XFD +(and non-compacted XSAVE saves the initial configuration of the state +component): + + If XSAVE, XSAVEC, XSAVEOPT, or XSAVES is saving the state component i, + the instruction does not generate #NM when XCR0[i] = IA32_XFD[i] = 1; + instead, it operates as if XINUSE[i] = 0 (and the state component was + in its initial state): it saves bit i of XSTATE_BV field of the XSAVE + header as 0; in addition, XSAVE saves the initial configuration of the + state component (the other instructions do not save state component i). + +Alternatively, KVM could always do XRSTOR with XFD=0, e.g. by using +a constant XFD based on the set of enabled features when XSAVEing for +a struct fpu_guest. However, having XSTATE_BV[i]=1 for XFD-disabled +features can only happen in the above interrupt case, or in similar +scenarios involving preemption on preemptible kernels, because +fpu_swap_kvm_fpstate()'s call to save_fpregs_to_fpstate() saves the +outgoing FPU state with the current XFD; and that is (on all but the +first WRMSR to XFD) the guest XFD. + +Therefore, XFD can only go out of sync with XSTATE_BV in the above +interrupt case, or in similar scenarios involving preemption on +preemptible kernels, and it we can consider it (de facto) part of KVM +ABI that KVM_GET_XSAVE returns XSTATE_BV[i]=0 for XFD-disabled features. + +Reported-by: Paolo Bonzini +Cc: stable@vger.kernel.org +Fixes: 820a6ee944e7 ("kvm: x86: Add emulation for IA32_XFD", 2022-01-14) +Signed-off-by: Sean Christopherson +[Move clearing of XSTATE_BV from fpu_copy_uabi_to_guest_fpstate + to kvm_vcpu_ioctl_x86_set_xsave. - Paolo] +Reviewed-by: Binbin Wu +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kernel/fpu/core.c | 32 +++++++++++++++++++++++++++++--- + arch/x86/kvm/x86.c | 9 +++++++++ + 2 files changed, 38 insertions(+), 3 deletions(-) + +--- a/arch/x86/kernel/fpu/core.c ++++ b/arch/x86/kernel/fpu/core.c +@@ -294,10 +294,29 @@ EXPORT_SYMBOL_GPL(fpu_enable_guest_xfd_f + #ifdef CONFIG_X86_64 + void fpu_update_guest_xfd(struct fpu_guest *guest_fpu, u64 xfd) + { ++ struct fpstate *fpstate = guest_fpu->fpstate; ++ + fpregs_lock(); +- guest_fpu->fpstate->xfd = xfd; +- if (guest_fpu->fpstate->in_use) +- xfd_update_state(guest_fpu->fpstate); ++ ++ /* ++ * KVM's guest ABI is that setting XFD[i]=1 *can* immediately revert the ++ * save state to its initial configuration. Likewise, KVM_GET_XSAVE does ++ * the same as XSAVE and returns XSTATE_BV[i]=0 whenever XFD[i]=1. ++ * ++ * If the guest's FPU state is in hardware, just update XFD: the XSAVE ++ * in fpu_swap_kvm_fpstate will clear XSTATE_BV[i] whenever XFD[i]=1. ++ * ++ * If however the guest's FPU state is NOT resident in hardware, clear ++ * disabled components in XSTATE_BV now, or a subsequent XRSTOR will ++ * attempt to load disabled components and generate #NM _in the host_. ++ */ ++ if (xfd && test_thread_flag(TIF_NEED_FPU_LOAD)) ++ fpstate->regs.xsave.header.xfeatures &= ~xfd; ++ ++ fpstate->xfd = xfd; ++ if (fpstate->in_use) ++ xfd_update_state(fpstate); ++ + fpregs_unlock(); + } + EXPORT_SYMBOL_GPL(fpu_update_guest_xfd); +@@ -406,6 +425,13 @@ int fpu_copy_uabi_to_guest_fpstate(struc + return -EINVAL; + + /* ++ * Disabled features must be in their initial state, otherwise XRSTOR ++ * causes an exception. ++ */ ++ if (WARN_ON_ONCE(ustate->xsave.header.xfeatures & kstate->xfd)) ++ return -EINVAL; ++ ++ /* + * Nullify @vpkru to preserve its current value if PKRU's bit isn't set + * in the header. KVM's odd ABI is to leave PKRU untouched in this + * case (all other components are eventually re-initialized). +--- a/arch/x86/kvm/x86.c ++++ b/arch/x86/kvm/x86.c +@@ -5625,9 +5625,18 @@ static int kvm_vcpu_ioctl_x86_get_xsave( + static int kvm_vcpu_ioctl_x86_set_xsave(struct kvm_vcpu *vcpu, + struct kvm_xsave *guest_xsave) + { ++ union fpregs_state *xstate = (union fpregs_state *)guest_xsave->region; ++ + if (fpstate_is_confidential(&vcpu->arch.guest_fpu)) + return vcpu->kvm->arch.has_protected_state ? -EINVAL : 0; + ++ /* ++ * For backwards compatibility, do not expect disabled features to be in ++ * their initial state. XSTATE_BV[i] must still be cleared whenever ++ * XFD[i]=1, or XRSTOR would cause a #NM. ++ */ ++ xstate->xsave.header.xfeatures &= ~vcpu->arch.guest_fpu.fpstate->xfd; ++ + return fpu_copy_uabi_to_guest_fpstate(&vcpu->arch.guest_fpu, + guest_xsave->region, + kvm_caps.supported_xcr0,