On Thu, Mar 19, 2020 at 10:35:49AM -0700, Sean Christopherson wrote: > On Thu, Mar 19, 2020 at 04:14:55PM +0100, Paolo Bonzini wrote: > > On 19/03/20 15:49, Sean Christopherson wrote: > > > On Thu, Mar 19, 2020 at 03:35:16AM -0700, syzbot wrote: > > >> syzbot has found a reproducer for the following crash on: > > >> > > >> HEAD commit: 5076190d mm: slub: be more careful about the double cmpxch.. > > >> git tree: upstream > > >> console output: https://syzkaller.appspot.com/x/log.txt?x=143ca61de00000 > > >> kernel config: https://syzkaller.appspot.com/x/.config?x=9f894bd92023de02 > > >> dashboard link: https://syzkaller.appspot.com/bug?extid=00be5da1d75f1cc95f6b > > >> compiler: gcc (GCC) 9.0.0 20181231 (experimental) > > >> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=10bb4023e00000 > > >> > > >> IMPORTANT: if you fix the bug, please add the following tag to the commit: > > >> Reported-by: syzbot+00be5da1d75f1cc95f6b@xxxxxxxxxxxxxxxxxxxxxxxxx > > > Reproduced with a little tweaking of the reproducer, debug in progress. > > > > > > > I think the WARN_ON at x86.c:2447 is just bogus. You can always get it > > to trigger if garbage is passed to KVM_SET_CLOCK. > > Yep. I worked through logic/math, mostly to gain a wee bit of knowledge > about the clock stuff, and it's sound. The KVM_SET_CLOCK from syzkaller > is simply making time go backwards. Actually, would it make sense to return -EINVAL for KVM_SET_CLOCK if the user tries to make kvmclock_offset go backwards?
