linux-kernel - Re: BUG: soft lockup in kvm_vm

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 24 Mar 2019 01:04:23 +0100 (CET)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     syzbot <syzbot+6349a512c2938b2ad058@...kaller.appspotmail.com>
cc:     andrea.parri@...rulasolutions.com, jpoimboe@...hat.com,
        linux-kernel@...r.kernel.org, luto@...nel.org, mingo@...nel.org,
        peterz@...radead.org, riel@...riel.com,
        syzkaller-bugs@...glegroups.com, torvalds@...ux-foundation.org
Subject: Re: BUG: soft lockup in kvm_vm_release

On Sat, 23 Mar 2019, syzbot wrote:

> syzbot has bisected this bug to:
> 
> commit 80eb865768703c0f85a0603762742ae1dedf21f0
> Author: Andrea Parri <andrea.parri@...rulasolutions.com>
> Date:   Tue Nov 27 11:01:10 2018 +0000
> 
>    sched/fair: Clean up comment in nohz_idle_balance()

I.m pretty sure that this bisect is bogus. The commit changes a comment not
code.

> bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=1362209b200000
> start commit:   57902dc0 Merge tag 'riscv-for-linus-5.0-rc7' of git://git...
> git tree:       upstream
> final crash:    https://syzkaller.appspot.com/x/report.txt?x=10e2209b200000
> console output: https://syzkaller.appspot.com/x/log.txt?x=1762209b200000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=ee434566c893c7b1
> dashboard link: https://syzkaller.appspot.com/bug?extid=6349a512c2938b2ad058
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=14287e78c00000
> 
> Reported-by: syzbot+6349a512c2938b2ad058@...kaller.appspotmail.com
> Fixes: 80eb86576870 ("sched/fair: Clean up comment in nohz_idle_balance()")
> 
> For information about bisection process see: https://goo.gl/tpsmEJ#bisection

If I understand that correctly, then the bisect does not try to revert the
commit which it identified on top of the tree where it started to bisect.

I think that'd be a reasonably simple to do extra data point, at least when
the commit reverts cleanly on head.

Thanks,

	tglx