* WARNING in switch_fpu_return @ 2020-01-02 2:25 syzbot 2020-01-07 20:53 ` Sebastian Andrzej Siewior 2020-03-22 22:41 ` syzbot 0 siblings, 2 replies; 7+ messages in thread From: syzbot @ 2020-01-02 2:25 UTC (permalink / raw) To: alexander.deucher, bigeasy, bp, dave.hansen, hpa, linux-kernel, mingo, nicholas.kazlauskas, riel, sunpeng.li, syzkaller-bugs, tglx, x86, zhan.liu 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: WARNING in switch_fpu_return 2020-01-02 2:25 WARNING in switch_fpu_return syzbot @ 2020-01-07 20:53 ` Sebastian Andrzej Siewior 2020-01-08 4:28 ` Dmitry Vyukov 2020-03-22 22:41 ` syzbot 1 sibling, 1 reply; 7+ messages in thread From: Sebastian Andrzej Siewior @ 2020-01-07 20:53 UTC (permalink / raw) To: syzbot Cc: alexander.deucher, bp, dave.hansen, hpa, linux-kernel, mingo, nicholas.kazlauskas, riel, sunpeng.li, syzkaller-bugs, tglx, x86, zhan.liu 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: WARNING in switch_fpu_return 2020-01-07 20:53 ` Sebastian Andrzej Siewior @ 2020-01-08 4:28 ` Dmitry Vyukov 2020-01-08 8:55 ` Sebastian Andrzej Siewior 0 siblings, 1 reply; 7+ messages in thread From: Dmitry Vyukov @ 2020-01-08 4:28 UTC (permalink / raw) To: Sebastian Andrzej Siewior Cc: syzbot, alexander.deucher, Borislav Petkov, Dave Hansen, H. Peter Anvin, LKML, Ingo Molnar, nicholas.kazlauskas, Rik van Riel, sunpeng.li, syzkaller-bugs, Thomas Gleixner, the arch/x86 maintainers, zhan.liu 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: WARNING in switch_fpu_return 2020-01-08 4:28 ` Dmitry Vyukov @ 2020-01-08 8:55 ` Sebastian Andrzej Siewior 2020-01-08 9:03 ` Dmitry Vyukov 0 siblings, 1 reply; 7+ messages in thread From: Sebastian Andrzej Siewior @ 2020-01-08 8:55 UTC (permalink / raw) To: Dmitry Vyukov Cc: syzbot, alexander.deucher, Borislav Petkov, Dave Hansen, H. Peter Anvin, LKML, Ingo Molnar, nicholas.kazlauskas, Rik van Riel, sunpeng.li, syzkaller-bugs, Thomas Gleixner, the arch/x86 maintainers, zhan.liu 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: WARNING in switch_fpu_return 2020-01-08 8:55 ` Sebastian Andrzej Siewior @ 2020-01-08 9:03 ` Dmitry Vyukov 0 siblings, 0 replies; 7+ messages in thread From: Dmitry Vyukov @ 2020-01-08 9:03 UTC (permalink / raw) To: Sebastian Andrzej Siewior Cc: syzbot, alexander.deucher, Borislav Petkov, Dave Hansen, H. Peter Anvin, LKML, Ingo Molnar, nicholas.kazlauskas, Rik van Riel, sunpeng.li, syzkaller-bugs, Thomas Gleixner, the arch/x86 maintainers, zhan.liu 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: WARNING in switch_fpu_return 2020-01-02 2:25 WARNING in switch_fpu_return syzbot 2020-01-07 20:53 ` Sebastian Andrzej Siewior @ 2020-03-22 22:41 ` syzbot 2020-03-23 15:01 ` Sean Christopherson 1 sibling, 1 reply; 7+ messages in thread From: syzbot @ 2020-03-22 22:41 UTC (permalink / raw) To: alexander.deucher, bigeasy, bp, dave.hansen, dvyukov, hpa, linmiaohe, linux-kernel, mingo, nicholas.kazlauskas, pbonzini, riel, sean.j.christopherson, sunpeng.li, syzkaller-bugs, tglx, x86, zhan.liu 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: WARNING in switch_fpu_return 2020-03-22 22:41 ` syzbot @ 2020-03-23 15:01 ` Sean Christopherson 0 siblings, 0 replies; 7+ messages in thread From: Sean Christopherson @ 2020-03-23 15:01 UTC (permalink / raw) To: syzbot Cc: alexander.deucher, bigeasy, bp, dave.hansen, dvyukov, hpa, linmiaohe, linux-kernel, mingo, nicholas.kazlauskas, pbonzini, riel, sunpeng.li, syzkaller-bugs, tglx, x86, zhan.liu 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2020-03-23 15:01 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-01-02 2:25 WARNING in switch_fpu_return syzbot 2020-01-07 20:53 ` Sebastian Andrzej Siewior 2020-01-08 4:28 ` Dmitry Vyukov 2020-01-08 8:55 ` Sebastian Andrzej Siewior 2020-01-08 9:03 ` Dmitry Vyukov 2020-03-22 22:41 ` syzbot 2020-03-23 15:01 ` Sean Christopherson
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).