Re: [tip: x86/fpu] x86/fpu/xstate: Define new functions for clearing fpregs and xstates
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- Subject: Re: [tip: x86/fpu] x86/fpu/xstate: Define new functions for clearing fpregs and xstates
- From: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
- Date: Tue, 25 May 2021 20:00:12 +0200
- Cc: linux-tip-commits@xxxxxxxxxxxxxxx, Fenghua Yu <fenghua.yu@xxxxxxxxx>, Borislav Petkov <bp@xxxxxxx>, Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx>, Tony Luck <tony.luck@xxxxxxxxx>, x86 <x86@xxxxxxxxxx>, "Shankar\, Ravi V" <ravi.v.shankar@xxxxxxxxx>
- In-reply-to: <10a553a5-699f-6921-705e-9afa1a8e42de@intel.com>
- References: <20200512145444.15483-6-yu-cheng.yu@intel.com> <158964181793.17951.15480349640697746223.tip-bot2@tip-bot2> <CALCETrXfLbsrBX42Y094YLWTG=pqkrf+aSCLruCGzqnZ0Y=P-Q@mail.gmail.com> <10a553a5-699f-6921-705e-9afa1a8e42de@intel.com>
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
[Index of Archives]
[Linux Stable Commits]
[Linux Stable Kernel]
[Linux Kernel]
[Linux USB Devel]
[Linux Video &Media]
[Linux Audio Users]
[Yosemite News]
[Linux SCSI]