[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87y2c28zir.ffs@nanos.tec.linutronix.de>
Date: Tue, 25 May 2021 20:00:12 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: "Yu\, Yu-cheng" <yu-cheng.yu@...el.com>,
Andy Lutomirski <luto@...nel.org>,
LKML <linux-kernel@...r.kernel.org>
Cc: linux-tip-commits@...r.kernel.org,
Fenghua Yu <fenghua.yu@...el.com>,
Borislav Petkov <bp@...e.de>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Tony Luck <tony.luck@...el.com>, x86 <x86@...nel.org>,
"Shankar\, Ravi V" <ravi.v.shankar@...el.com>
Subject: Re: [tip: x86/fpu] x86/fpu/xstate: Define new functions for clearing fpregs and xstates
On Tue, May 25 2021 at 10:44, Yu-cheng Yu wrote:
> On 5/24/2021 9:34 AM, Andy Lutomirski wrote:
>> So I'm guessing that syzbot may have misattributed the problem. But
>> we definitely need to clean up the XRSTOR #GP handling before CET
>> lands.
>>
> From the crash dump, the system is doing syscall_exit_to_user_mode()
> for __x64_sys_futex(). The futex syscall does not seem to modify
> xstates,
Of course does the futex syscall not modify anything, but the task can
schedule out before returning from the syscall so it has to restore the
FPU state.
> but upon returning to user mode, XRSTORS gets a GP. Can this
> be some memory corruption? fpu__clear() is merely helping to clear the
> mess and seems to be innocent.
What kind of analysis is that?
Thanks,
tglx
Powered by blists - more mailing lists