WARNING in switch_fpu_return

WARNING in switch_fpu_return

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit:    bf8d1cd4 Merge tag 'scsi-fixes' of git://git.kernel.org/pu..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=17a4ce15e00000
kernel config:  https://syzkaller.appspot.com/x/.config?x=ed9d672709340e35
dashboard link: https://syzkaller.appspot.com/bug?extid=f2ca20d4aa1408b0385a
compiler:       gcc (GCC) 9.0.0 20181231 (experimental)
userspace arch: i386
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=10cc8971e00000

The bug was bisected to:

commit 92e6475ae0a0383b012eb21c1aaf0e5456b1a3d9
Author: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Date:   Wed Jul 3 14:02:39 2019 +0000

     drm/amd/display: Set enabled to false at start of audio disable

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=15614e3ee00000
console output: https://syzkaller.appspot.com/x/log.txt?x=13614e3ee00000

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+f2ca20d4aa1408b0385a@syzkaller.appspotmail.com
Fixes: 92e6475ae0a0 ("drm/amd/display: Set enabled to false at start of  
audio disable")

------------[ cut here ]------------
WARNING: CPU: 0 PID: 2862 at arch/x86/include/asm/fpu/internal.h:539  
__fpregs_load_activate arch/x86/include/asm/fpu/internal.h:539 [inline]
WARNING: CPU: 0 PID: 2862 at arch/x86/include/asm/fpu/internal.h:539  
switch_fpu_return+0x437/0x4f0 arch/x86/kernel/fpu/core.c:343
Kernel panic - not syncing: panic_on_warn set ...
CPU: 0 PID: 2862 Comm: kworker/0:3 Not tainted 5.5.0-rc3-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011
Workqueue: events async_pf_execute
Call Trace:
  __dump_stack lib/dump_stack.c:77 [inline]
  dump_stack+0x197/0x210 lib/dump_stack.c:118
  panic+0x2e3/0x75c kernel/panic.c:221
  __warn.cold+0x2f/0x3e kernel/panic.c:582
  report_bug+0x289/0x300 lib/bug.c:195
  fixup_bug arch/x86/kernel/traps.c:174 [inline]
  fixup_bug arch/x86/kernel/traps.c:169 [inline]
  do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:267
  do_invalid_op+0x37/0x50 arch/x86/kernel/traps.c:286
  invalid_op+0x23/0x30 arch/x86/entry/entry_64.S:1027
RIP: 0010:__fpregs_load_activate arch/x86/include/asm/fpu/internal.h:539  
[inline]
RIP: 0010:switch_fpu_return+0x437/0x4f0 arch/x86/kernel/fpu/core.c:343
Code: 0f 94 c6 31 ff 44 89 f6 e8 06 8f 4a 00 45 84 f6 0f 84 7f fd ff ff e8  
b8 8d 4a 00 e8 a4 c9 d5 ff e9 70 fd ff ff e8 a9 8d 4a 00 <0f> 0b e9 b6 fd  
ff ff e8 9d 8d 4a 00 0f 0b e9 18 fd ff ff e8 91 8d
RSP: 0018:ffffc90007ecfa80 EFLAGS: 00010293
RAX: ffff88809f60e0c0 RBX: ffff88809f60e0c0 RCX: ffffffff812a9ccf
RDX: 0000000000000000 RSI: ffffffff812aa047 RDI: 0000000000000005
RBP: ffffc90007ecfb10 R08: ffff88809f60e0c0 R09: ffffed1013ec1c19
R10: ffffed1013ec1c18 R11: ffff88809f60e0c7 R12: 1ffff92000fd9f51
R13: ffff88809f60f5c0 R14: 0000000000200000 R15: ffffc90007ecfae8
  kvm_arch_vcpu_load+0x66e/0x950 arch/x86/kvm/x86.c:3463
  vcpu_load+0x43/0x90 arch/x86/kvm/../../../virt/kvm/kvm_main.c:201
  kvm_unload_vcpu_mmu arch/x86/kvm/x86.c:9543 [inline]
  kvm_free_vcpus arch/x86/kvm/x86.c:9558 [inline]
  kvm_arch_destroy_vm+0x184/0x5f0 arch/x86/kvm/x86.c:9663
  kvm_destroy_vm arch/x86/kvm/../../../virt/kvm/kvm_main.c:816 [inline]
  kvm_put_kvm+0x5a5/0xcc0 arch/x86/kvm/../../../virt/kvm/kvm_main.c:837
  async_pf_execute+0x3bf/0x800 arch/x86/kvm/../../../virt/kvm/async_pf.c:101
  process_one_work+0x9af/0x1740 kernel/workqueue.c:2264
  worker_thread+0x98/0xe40 kernel/workqueue.c:2410
  kthread+0x361/0x430 kernel/kthread.c:255
  ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
Kernel Offset: disabled
Rebooting in 86400 seconds..


---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.

syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches

Re: WARNING in switch_fpu_return

[Sebastian Andrzej Siewior]

On 2020-01-01 18:25:09 [-0800], syzbot wrote:
> Hello,
> 
> syzbot found the following crash on:
> 
> HEAD commit:    bf8d1cd4 Merge tag 'scsi-fixes' of git://git.kernel.org/pu..
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=17a4ce15e00000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=ed9d672709340e35
> dashboard link: https://syzkaller.appspot.com/bug?extid=f2ca20d4aa1408b0385a
> compiler:       gcc (GCC) 9.0.0 20181231 (experimental)
> userspace arch: i386
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=10cc8971e00000

So I tried to reproduce this. syz-prog2c made .c out of the above link.
It starts with:
|int main(void)
| {
|   syscall(__NR_mmap, 0x20000000ul, 0x1000000ul, 3ul, 0x32ul, -1, 0);

and segfaults on execution. The problem is that for for 32bit-x86 this
should be __NR_mmap2 instead. This fixed the mmap() calls however the
openat() still failed… Nothing bad happened in the end since all the
syscalls failed "early".
As a 64bit binary, it is a different story:
- On a Intel box the KVM_RUN ioctl() worked and did not return (CTRL-C
  ended the ioctl() without an error/warning)
- On a AMD box the KVM_RUN ioctl() triggered a reboot of the kvm guest.

> The bug was bisected to:
> 
> commit 92e6475ae0a0383b012eb21c1aaf0e5456b1a3d9
> Author: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
> Date:   Wed Jul 3 14:02:39 2019 +0000
> 
>     drm/amd/display: Set enabled to false at start of audio disable
> 
> bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=15614e3ee00000

This commit changes a file which is not compiled by the config provided.

> console output: https://syzkaller.appspot.com/x/log.txt?x=13614e3ee00000

> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+f2ca20d4aa1408b0385a@syzkaller.appspotmail.com
> Fixes: 92e6475ae0a0 ("drm/amd/display: Set enabled to false at start of
> audio disable")
> 
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 2862 at arch/x86/include/asm/fpu/internal.h:539
> __fpregs_load_activate arch/x86/include/asm/fpu/internal.h:539 [inline]
> WARNING: CPU: 0 PID: 2862 at arch/x86/include/asm/fpu/internal.h:539
> switch_fpu_return+0x437/0x4f0 arch/x86/kernel/fpu/core.c:343
> Kernel panic - not syncing: panic_on_warn set ...
> CPU: 0 PID: 2862 Comm: kworker/0:3 Not tainted 5.5.0-rc3-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Workqueue: events async_pf_execute
> Call Trace:
…
> ff e8 9d 8d 4a 00 0f 0b e9 18 fd ff ff e8 91 8d
> RSP: 0018:ffffc90007ecfa80 EFLAGS: 00010293
> RAX: ffff88809f60e0c0 RBX: ffff88809f60e0c0 RCX: ffffffff812a9ccf
> RDX: 0000000000000000 RSI: ffffffff812aa047 RDI: 0000000000000005
> RBP: ffffc90007ecfb10 R08: ffff88809f60e0c0 R09: ffffed1013ec1c19
> R10: ffffed1013ec1c18 R11: ffff88809f60e0c7 R12: 1ffff92000fd9f51
> R13: ffff88809f60f5c0 R14: 0000000000200000 R15: ffffc90007ecfae8
>  kvm_arch_vcpu_load+0x66e/0x950 arch/x86/kvm/x86.c:3463
>  vcpu_load+0x43/0x90 arch/x86/kvm/../../../virt/kvm/kvm_main.c:201
>  kvm_unload_vcpu_mmu arch/x86/kvm/x86.c:9543 [inline]
>  kvm_free_vcpus arch/x86/kvm/x86.c:9558 [inline]
>  kvm_arch_destroy_vm+0x184/0x5f0 arch/x86/kvm/x86.c:9663
>  kvm_destroy_vm arch/x86/kvm/../../../virt/kvm/kvm_main.c:816 [inline]
>  kvm_put_kvm+0x5a5/0xcc0 arch/x86/kvm/../../../virt/kvm/kvm_main.c:837
>  async_pf_execute+0x3bf/0x800 arch/x86/kvm/../../../virt/kvm/async_pf.c:101
>  process_one_work+0x9af/0x1740 kernel/workqueue.c:2264
>  worker_thread+0x98/0xe40 kernel/workqueue.c:2410
>  kthread+0x361/0x430 kernel/kthread.c:255
>  ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
> Kernel Offset: disabled
> Rebooting in 86400 seconds..

As part of kvm_arch_vcpu_load() switch_fpu_return() is invoked which
triggers the warning. The problem is that a workqueue should have
TIF_NEED_FPU_LOAD set. I have no idea how that one got set since it
should not be set for kernel threads.

Sebastian

Re: WARNING in switch_fpu_return

[Dmitry Vyukov]

On Tue, Jan 7, 2020 at 9:53 PM Sebastian Andrzej Siewior
<bigeasy@linutronix.de> wrote:
>
> On 2020-01-01 18:25:09 [-0800], syzbot wrote:
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit:    bf8d1cd4 Merge tag 'scsi-fixes' of git://git.kernel.org/pu..
> > git tree:       upstream
> > console output: https://syzkaller.appspot.com/x/log.txt?x=17a4ce15e00000
> > kernel config:  https://syzkaller.appspot.com/x/.config?x=ed9d672709340e35
> > dashboard link: https://syzkaller.appspot.com/bug?extid=f2ca20d4aa1408b0385a
> > compiler:       gcc (GCC) 9.0.0 20181231 (experimental)
> > userspace arch: i386
> > syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=10cc8971e00000
>
> So I tried to reproduce this. syz-prog2c made .c out of the above link.
> It starts with:
> |int main(void)
> | {
> |   syscall(__NR_mmap, 0x20000000ul, 0x1000000ul, 3ul, 0x32ul, -1, 0);

Hi Sebastian,

If you want to generate a C repro for 386 arch, you need to add
-arch=386 flag to syz-prog2c (then it hopefully should use mmap2).
But FWIW syzbot wasn't able to reproduce it with a C program,
otherwise it would have been provided it. But that may be for various
reasons.

> and segfaults on execution. The problem is that for for 32bit-x86 this
> should be __NR_mmap2 instead. This fixed the mmap() calls however the
> openat() still failed… Nothing bad happened in the end since all the
> syscalls failed "early".
> As a 64bit binary, it is a different story:
> - On a Intel box the KVM_RUN ioctl() worked and did not return (CTRL-C
>   ended the ioctl() without an error/warning)
> - On a AMD box the KVM_RUN ioctl() triggered a reboot of the kvm guest.
>
> > The bug was bisected to:
> >
> > commit 92e6475ae0a0383b012eb21c1aaf0e5456b1a3d9
> > Author: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
> > Date:   Wed Jul 3 14:02:39 2019 +0000
> >
> >     drm/amd/display: Set enabled to false at start of audio disable
> >
> > bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=15614e3ee00000
>
> This commit changes a file which is not compiled by the config provided.

I've added a reference here:
https://github.com/google/syzkaller/issues/1271#issuecomment-559093018

But I don't know what's the reason for non-deterministic builds yet.
Anyhow it _did_ affect the vmlinux.

> > console output: https://syzkaller.appspot.com/x/log.txt?x=13614e3ee00000
>
> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > Reported-by: syzbot+f2ca20d4aa1408b0385a@syzkaller.appspotmail.com
> > Fixes: 92e6475ae0a0 ("drm/amd/display: Set enabled to false at start of
> > audio disable")
> >
> > ------------[ cut here ]------------
> > WARNING: CPU: 0 PID: 2862 at arch/x86/include/asm/fpu/internal.h:539
> > __fpregs_load_activate arch/x86/include/asm/fpu/internal.h:539 [inline]
> > WARNING: CPU: 0 PID: 2862 at arch/x86/include/asm/fpu/internal.h:539
> > switch_fpu_return+0x437/0x4f0 arch/x86/kernel/fpu/core.c:343
> > Kernel panic - not syncing: panic_on_warn set ...
> > CPU: 0 PID: 2862 Comm: kworker/0:3 Not tainted 5.5.0-rc3-syzkaller #0
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > Google 01/01/2011
> > Workqueue: events async_pf_execute
> > Call Trace:
> …
> > ff e8 9d 8d 4a 00 0f 0b e9 18 fd ff ff e8 91 8d
> > RSP: 0018:ffffc90007ecfa80 EFLAGS: 00010293
> > RAX: ffff88809f60e0c0 RBX: ffff88809f60e0c0 RCX: ffffffff812a9ccf
> > RDX: 0000000000000000 RSI: ffffffff812aa047 RDI: 0000000000000005
> > RBP: ffffc90007ecfb10 R08: ffff88809f60e0c0 R09: ffffed1013ec1c19
> > R10: ffffed1013ec1c18 R11: ffff88809f60e0c7 R12: 1ffff92000fd9f51
> > R13: ffff88809f60f5c0 R14: 0000000000200000 R15: ffffc90007ecfae8
> >  kvm_arch_vcpu_load+0x66e/0x950 arch/x86/kvm/x86.c:3463
> >  vcpu_load+0x43/0x90 arch/x86/kvm/../../../virt/kvm/kvm_main.c:201
> >  kvm_unload_vcpu_mmu arch/x86/kvm/x86.c:9543 [inline]
> >  kvm_free_vcpus arch/x86/kvm/x86.c:9558 [inline]
> >  kvm_arch_destroy_vm+0x184/0x5f0 arch/x86/kvm/x86.c:9663
> >  kvm_destroy_vm arch/x86/kvm/../../../virt/kvm/kvm_main.c:816 [inline]
> >  kvm_put_kvm+0x5a5/0xcc0 arch/x86/kvm/../../../virt/kvm/kvm_main.c:837
> >  async_pf_execute+0x3bf/0x800 arch/x86/kvm/../../../virt/kvm/async_pf.c:101
> >  process_one_work+0x9af/0x1740 kernel/workqueue.c:2264
> >  worker_thread+0x98/0xe40 kernel/workqueue.c:2410
> >  kthread+0x361/0x430 kernel/kthread.c:255
> >  ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
> > Kernel Offset: disabled
> > Rebooting in 86400 seconds..
>
> As part of kvm_arch_vcpu_load() switch_fpu_return() is invoked which
> triggers the warning. The problem is that a workqueue should have
> TIF_NEED_FPU_LOAD set. I have no idea how that one got set since it
> should not be set for kernel threads.
>
> Sebastian
>
> --
> You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/20200107205302.45yb2rkekz3nat6v%40linutronix.de.

Re: WARNING in switch_fpu_return

[Sebastian Andrzej Siewior]

Hi Dmitry,

On 2020-01-08 05:28:31 [+0100], Dmitry Vyukov wrote:
> > > userspace arch: i386
> >
> > So I tried to reproduce this. syz-prog2c made .c out of the above link.
> > It starts with:
> > |int main(void)
> > | {
> > |   syscall(__NR_mmap, 0x20000000ul, 0x1000000ul, 3ul, 0x32ul, -1, 0);
> 
> Hi Sebastian,
> 
> If you want to generate a C repro for 386 arch, you need to add
> -arch=386 flag to syz-prog2c (then it hopefully should use mmap2).

Ah okay. I've been looking at
	https://github.com/google/syzkaller/blob/master/docs/syzbot.md#crash-does-not-reproduce

and it says
|Note: if the report contains userspace arch: i386, then the program
|needs to be built with -m32 flag.

and with the argument you mentioned it the compiled C code uses mmap2.
Thanks.
Now the 32bit testcase reboots, too :)

> But FWIW syzbot wasn't able to reproduce it with a C program,
> otherwise it would have been provided it. But that may be for various
> reasons.

Yeah, my memory was also that a C-testcase is provided. But there was this
	https://syzkaller.appspot.com/x/repro.syz?x=10cc8971e00000

link so I assumed I should use it myself and I missed the update that
something changed.
So what should I do with the file above? Feed it to `syz-execprog' or is
it a rough idea what the test case should have done?

Sebastian

Re: WARNING in switch_fpu_return

[Dmitry Vyukov]

On Wed, Jan 8, 2020 at 9:55 AM Sebastian Andrzej Siewior
<bigeasy@linutronix.de> wrote:
>
> Hi Dmitry,
>
> On 2020-01-08 05:28:31 [+0100], Dmitry Vyukov wrote:
> > > > userspace arch: i386
> > >
> > > So I tried to reproduce this. syz-prog2c made .c out of the above link.
> > > It starts with:
> > > |int main(void)
> > > | {
> > > |   syscall(__NR_mmap, 0x20000000ul, 0x1000000ul, 3ul, 0x32ul, -1, 0);
> >
> > Hi Sebastian,
> >
> > If you want to generate a C repro for 386 arch, you need to add
> > -arch=386 flag to syz-prog2c (then it hopefully should use mmap2).
>
> Ah okay. I've been looking at
>         https://github.com/google/syzkaller/blob/master/docs/syzbot.md#crash-does-not-reproduce
>
> and it says
> |Note: if the report contains userspace arch: i386, then the program
> |needs to be built with -m32 flag.
>
> and with the argument you mentioned it the compiled C code uses mmap2.
> Thanks.
> Now the 32bit testcase reboots, too :)
>
> > But FWIW syzbot wasn't able to reproduce it with a C program,
> > otherwise it would have been provided it. But that may be for various
> > reasons.
>
> Yeah, my memory was also that a C-testcase is provided. But there was this
>         https://syzkaller.appspot.com/x/repro.syz?x=10cc8971e00000
>
> link so I assumed I should use it myself and I missed the update that
> something changed.
> So what should I do with the file above? Feed it to `syz-execprog' or is
> it a rough idea what the test case should have done?

Yes, the syz program can be executed with syz-execprog utility:

https://github.com/google/syzkaller/blob/master/docs/executing_syzkaller_programs.md

However, since it's a KVM bug, it may be somewhat special. At least
there were some special ones historically. For example, behavior may
also depend on the host OS. So maybe you already reproduced it, it's
just that in syzbot environment it caused the WARNING, but in your
environment it causes the reboot. I have no indication that it's
actually the case. But I just want to warn that reproduction of some
KVM bugs proved to be tricky in the past. I am sure that syzbot was
able to trigger that exact warning on that exact kernel version/config
using that exact program. But it happened in one particular
environment.

Re: WARNING in switch_fpu_return

[syzbot]

syzbot suspects this bug was fixed by commit:

commit 3009afc6e39e78708d8fb444ae50544b3bcd3a3f
Author: Sean Christopherson <sean.j.christopherson@intel.com>
Date:   Wed Jan 22 04:43:39 2020 +0000

    KVM: x86: Use a typedef for fastop functions

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=1667aa4be00000
start commit:   bf8d1cd4 Merge tag 'scsi-fixes' of git://git.kernel.org/pu..
git tree:       upstream
kernel config:  https://syzkaller.appspot.com/x/.config?x=ed9d672709340e35
dashboard link: https://syzkaller.appspot.com/bug?extid=f2ca20d4aa1408b0385a
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=151d549ee00000

If the result looks correct, please mark the bug fixed by replying with:

#syz fix: KVM: x86: Use a typedef for fastop functions

For information about bisection process see: https://goo.gl/tpsmEJ#bisection

Re: WARNING in switch_fpu_return

[Sean Christopherson]

On Sun, Mar 22, 2020 at 03:41:03PM -0700, syzbot wrote:
> syzbot suspects this bug was fixed by commit:
> 
> commit 3009afc6e39e78708d8fb444ae50544b3bcd3a3f
> Author: Sean Christopherson <sean.j.christopherson@intel.com>
> Date:   Wed Jan 22 04:43:39 2020 +0000
> 
>     KVM: x86: Use a typedef for fastop functions
> 
> bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=1667aa4be00000
> start commit:   bf8d1cd4 Merge tag 'scsi-fixes' of git://git.kernel.org/pu..
> git tree:       upstream
> kernel config:  https://syzkaller.appspot.com/x/.config?x=ed9d672709340e35
> dashboard link: https://syzkaller.appspot.com/bug?extid=f2ca20d4aa1408b0385a
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=151d549ee00000
> 
> If the result looks correct, please mark the bug fixed by replying with:
> 
> #syz fix: KVM: x86: Use a typedef for fastop functions

Ha, fat chance of that.

The offending call to switch_fpu_return() in kvm_arch_vcpu_load() was
removed by commit 2620fe268e80 ("KVM: x86: Revert "KVM: X86: Fix fpu state
crash in kvm guest"")

 RIP: 0010:__fpregs_load_activate arch/x86/include/asm/fpu/internal.h:539 [inline]
 RIP: 0010:switch_fpu_return+0x437/0x4f0 arch/x86/kernel/fpu/core.c:343
  kvm_arch_vcpu_load+0x66e/0x950 arch/x86/kvm/x86.c:3463
  vcpu_load+0x43/0x90 arch/x86/kvm/../../../virt/kvm/kvm_main.c:201
  kvm_unload_vcpu_mmu arch/x86/kvm/x86.c:9543 [inline]
  kvm_free_vcpus arch/x86/kvm/x86.c:9558 [inline]
  kvm_arch_destroy_vm+0x184/0x5f0 arch/x86/kvm/x86.c:9663
  kvm_destroy_vm arch/x86/kvm/../../../virt/kvm/kvm_main.c:816 [inline]
  kvm_put_kvm+0x5a5/0xcc0 arch/x86/kvm/../../../virt/kvm/kvm_main.c:837
  async_pf_execute+0x3bf/0x800 arch/x86/kvm/../../../virt/kvm/async_pf.c:101
  process_one_work+0x9af/0x1740 kernel/workqueue.c:2264
  worker_thread+0x98/0xe40 kernel/workqueue.c:2410
  kthread+0x361/0x430 kernel/kthread.c:255
  ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352

So

#syz fix: KVM: x86: Revert "KVM: X86: Fix fpu state crash in kvm guest"

> For information about bisection process see: https://goo.gl/tpsmEJ#bisection