[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <2939ec67-4d27-13bb-e1a5-24fba0ba86c0@intel.com>
Date: Tue, 8 Feb 2022 11:21:34 -0800
From: Dave Hansen <dave.hansen@...el.com>
To: syzbot <syzbot+3c0a98026cec79f550a2@...kaller.appspotmail.com>,
bp@...en8.de, dave.hansen@...ux.intel.com, hpa@...or.com,
linux-kernel@...r.kernel.org, mingo@...hat.com,
syzkaller-bugs@...glegroups.com, tglx@...utronix.de, x86@...nel.org
Subject: Re: [syzbot] WARNING in fpregs_assert_state_consistent
On 2/8/22 00:31, syzbot wrote:
> Call Trace:
> <TASK>
> arch_exit_to_user_mode_prepare arch/x86/include/asm/entry-common.h:56 [inline]
> exit_to_user_mode_prepare+0x57/0x290 kernel/entry/common.c:209
> __syscall_exit_to_user_mode_work kernel/entry/common.c:289 [inline]
> syscall_exit_to_user_mode+0x19/0x60 kernel/entry/common.c:300
> do_syscall_64+0x42/0xb0 arch/x86/entry/common.c:86
> entry_SYSCALL_64_after_hwframe+0x44/0xae
Just in case it saves anyone else the trouble...
This is a WARN_ON_FPU() that triggers inside
fpregs_assert_state_consistent() because TIF_NEED_FPU_LOAD is clear
while !fpregs_state_valid().
In other words, the FPU registers are *in*valid, but they're also not
marked to be reloaded. They must be valid before returning to userspace.
The stack trace is not very helpful because it's almost empty on the
return to userspace.
I don't see anything x86-FPU-specific between 5.17-rc2 and the
linux-next commit in question.
I think we need to wait on a reproducer or a more revealing warning.
Powered by blists - more mailing lists