From: Sean Christopherson <seanjc@google.com>
To: Chao Gao <chao.gao@intel.com>
Cc: "Chang S. Bae" <chang.seok.bae@intel.com>,
mingo@redhat.com, linux-kernel@vger.kernel.org, x86@kernel.org,
tglx@linutronix.de, bp@alien8.de, dave.hansen@linux.intel.com,
stable@vger.kernel.org
Subject: Re: [PATCH] x86/fpu: Ensure XFD state on signal delivery
Date: Tue, 28 Oct 2025 10:37:53 -0700 [thread overview]
Message-ID: <aQD_cZzqml1vindY@google.com> (raw)
In-Reply-To: <aEeAl9Hp7sSizrl8@intel.com>
On Tue, Jun 10, 2025, Chao Gao wrote:
> On Mon, Jun 09, 2025 at 05:16:59PM -0700, Chang S. Bae wrote:
> >Sean reported [1] the following splat when running KVM tests:
> >
> > WARNING: CPU: 232 PID: 15391 at xfd_validate_state+0x65/0x70
> > Call Trace:
> > <TASK>
> > fpu__clear_user_states+0x9c/0x100
> > arch_do_signal_or_restart+0x142/0x210
> > exit_to_user_mode_loop+0x55/0x100
> > do_syscall_64+0x205/0x2c0
> > entry_SYSCALL_64_after_hwframe+0x4b/0x53
> >
> >Chao further identified [2] a reproducible scenarios involving signal
> >delivery: a non-AMX task is preempted by an AMX-enabled task which
> >modifies the XFD MSR.
> >
> >When the non-AMX task resumes and reloads XSTATE with init values,
> >a warning is triggered due to a mismatch between fpstate::xfd and the
> >CPU's current XFD state. fpu__clear_user_states() does not currently
> >re-synchronize the XFD state after such preemption.
> >
> >Invoke xfd_update_state() which detects and corrects the mismatch if the
> >dynamic feature is enabled.
> >
> >This also benefits the sigreturn path, as fpu__restore_sig() may call
> >fpu__clear_user_states() when the sigframe is inaccessible.
> >
> >Fixes: 672365477ae8a ("x86/fpu: Update XFD state where required")
> >Reported-by: Sean Christopherson <seanjc@google.com>
> >Closes: https://lore.kernel.org/lkml/aDCo_SczQOUaB2rS@google.com [1]
> >Tested-by: Chao Gao <chao.gao@intel.com>
> >Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com>
> >Cc: stable@vger.kernel.org
> >Link: https://lore.kernel.org/all/aDWbctO%2FRfTGiCg3@intel.com [2]
>
> Reviewed-by: Chao Gao <chao.gao@intel.com>
>
> Thanks for looking into this issue.
Ping. I _think_ this is still needed? AFAICT, it just fell through the cracks.
prev parent reply other threads:[~2025-10-28 17:37 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-10 0:16 [PATCH] x86/fpu: Ensure XFD state on signal delivery Chang S. Bae
2025-06-10 0:47 ` Chao Gao
2025-10-28 17:37 ` Sean Christopherson [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aQD_cZzqml1vindY@google.com \
--to=seanjc@google.com \
--cc=bp@alien8.de \
--cc=chang.seok.bae@intel.com \
--cc=chao.gao@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=stable@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.