[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aFtYqW5jGcgeDf4n@intel.com>
Date: Wed, 25 Jun 2025 10:02:17 +0800
From: Chao Gao <chao.gao@...el.com>
To: Dave Hansen <dave.hansen@...ux.intel.com>
CC: <linux-kernel@...r.kernel.org>, <x86@...nel.org>, <tglx@...utronix.de>,
<bp@...en8.de>, <mingo@...nel.org>, Alison Schofield
<alison.schofield@...el.com>, Chang S.Bae <chang.seok.bae@...el.com>, "Eric
Biggers" <ebiggers@...gle.com>, Rik van Riel <riel@...hat.com>,
<stable@...r.kernel.org>
Subject: Re: [PATCH] [v2] x86/fpu: Delay instruction pointer fixup until
after warning
On Tue, Jun 24, 2025 at 02:01:48PM -0700, Dave Hansen wrote:
>
>Changes from v1:
> * Fix minor typos
> * Use the more generic and standard ex_handler_default(). Had the
> original code used this helper, the bug would not have been there
> in the first place.
>
>--
>
>From: Dave Hansen <dave.hansen@...ux.intel.com>
>
>Right now, if XRSTOR fails a console message like this is be printed:
>
> Bad FPU state detected at restore_fpregs_from_fpstate+0x9a/0x170, reinitializing FPU registers.
>
>However, the text location (...+0x9a in this case) is the instruction
>*AFTER* the XRSTOR. The highlighted instruction in the "Code:" dump
>also points one instruction late.
>
>The reason is that the "fixup" moves RIP up to pass the bad XRSTOR and
>keep on running after returning from the #GP handler. But it does this
>fixup before warning.
>
>The resulting warning output is nonsensical because it looks like the
>non-FPU-related instruction is #GP'ing.
>
>Do not fix up RIP until after printing the warning. Do this by using
>the more generic and standard ex_handler_default().
>
>Signed-off-by: Dave Hansen <dave.hansen@...ux.intel.com>
>Fixes: d5c8028b4788 ("x86/fpu: Reinitialize FPU registers if restoring FPU state fails")
>Acked-by: Alison Schofield <alison.schofield@...el.com>
Reviewed-by: Chao Gao <chao.gao@...el.com>
Powered by blists - more mailing lists