[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191122205453.GE31235@linux.intel.com>
Date: Fri, 22 Nov 2019 12:54:53 -0800
From: Sean Christopherson <sean.j.christopherson@...el.com>
To: syzbot <syzbot+7e2ab84953e4084a638d@...kaller.appspotmail.com>
Cc: casey@...aufler-ca.com, frederic@...nel.org,
gregkh@...uxfoundation.org, hpa@...or.com, jmattson@...gle.com,
jmorris@...ei.org, karahmed@...zon.de,
kstewart@...uxfoundation.org, kvm@...r.kernel.org,
linux-kernel@...r.kernel.org,
linux-security-module@...r.kernel.org, mingo@...nel.org,
mingo@...hat.com, pasha.tatashin@...cle.com, pbonzini@...hat.com,
pombredanne@...b.com, rkrcmar@...hat.com, serge@...lyn.com,
syzkaller-bugs@...glegroups.com, tglx@...utronix.de, x86@...nel.org
Subject: Re: general protection fault in __schedule (2)
On Thu, Nov 21, 2019 at 11:19:00PM -0800, syzbot wrote:
> syzbot has bisected this bug to:
>
> commit 8fcc4b5923af5de58b80b53a069453b135693304
> Author: Jim Mattson <jmattson@...gle.com>
> Date: Tue Jul 10 09:27:20 2018 +0000
>
> kvm: nVMX: Introduce KVM_CAP_NESTED_STATE
>
> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=124cdbace00000
> start commit: 234b69e3 ocfs2: fix ocfs2 read block panic
> git tree: upstream
> final crash: https://syzkaller.appspot.com/x/report.txt?x=114cdbace00000
> console output: https://syzkaller.appspot.com/x/log.txt?x=164cdbace00000
> kernel config: https://syzkaller.appspot.com/x/.config?x=5fa12be50bca08d8
> dashboard link: https://syzkaller.appspot.com/bug?extid=7e2ab84953e4084a638d
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=150f0a4e400000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17f67111400000
>
> Reported-by: syzbot+7e2ab84953e4084a638d@...kaller.appspotmail.com
> Fixes: 8fcc4b5923af ("kvm: nVMX: Introduce KVM_CAP_NESTED_STATE")
>
> For information about bisection process see: https://goo.gl/tpsmEJ#bisection
Is there a way to have syzbot stop processing/bisecting these things
after a reasonable amount of time? The original crash is from August of
last year...
Note, the original crash is actually due to KVM's put_kvm() fd race, but
whatever we want to blame, it's a duplicate.
#syz dup: general protection fault in kvm_lapic_hv_timer_in_use
Powered by blists - more mailing lists