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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Tue, 23 Apr 2019 17:41:40 +0300
From:   Dmitry Vyukov <>
To:     Linus Torvalds <>
Cc:     Jens Axboe <>,
        syzbot <>,
        Arnd Bergmann <>, Borislav Petkov <>,
        "Darrick J. Wong" <>,
        Greg Kroah-Hartman <>,
        Peter Anvin <>,
        Linux API <>,
        linux-arch <>,
        linux-block <>,
        linux-fsdevel <>,
        Linux List Kernel Mailing <>,
        Andrew Lutomirski <>,
        Mathieu Desnoyers <>,
        Ingo Molnar <>,
        Michael Ellerman <>,
        syzkaller-bugs <>,
        Thomas Gleixner <>,
        Al Viro <>,
        "the arch/x86 maintainers" <>,
        syzkaller <>
Subject: Re: WARNING in percpu_ref_kill_and_confirm

On Mon, Apr 22, 2019 at 7:48 PM Linus Torvalds
<> wrote:
> On Mon, Apr 22, 2019 at 9:38 AM Jens Axboe <> wrote:
> >
> > With the mutex change in, I can trigger it in a second or so. Just ran
> > the reproducer with that change reverted, and I'm not seeing any badness.
> > So I do wonder if the bisect results are accurate?
> Looking at the syzbot report, it's syzbot being confused.
> The actual WARNING in percpu_ref_kill_and_confirm() only happens with
> recent kernels.
> But then syzbot mixes it up with a completely different bug:
>    crash: BUG: MAX_STACK_TRACE_ENTRIES too low!
> and for some reason decides that *that* bug is the same thing entirely.
> So yeah, I think the simple percpu_ref_is_dying() check is sufficient,
> and that the syzbot bisection is completely bogus.

Using crashed/not-crashed predicate gives better results overall. More
than half kernel bugs have different manifestations due to different
reasons. And even if we can say for sure that we see a different bug,
we still don't know if the original bug is also there or not. See the
following threads for details:

Unrelated crashes is the most common cause of incorrect bisection
results (66%). To enable better bisection we would need to integrate
some meaningful precommit testing into kernel development process
(would be tremendously useful for other reasons too). E.g. this "BUG:
MAX_STACK_TRACE_ENTRIES too low!" is this:
and the reproducer is simply opening /dev/infiniband/rdma_cm or
/dev/vhci or something equally simple with LOCKDEP enabled. None of
this was done in a testing environment for several weeks. And then it
took another month to propagate the fix through all distributed kernel
trees. For all that time simple programs crash and bisection can't be
done and we are spending time here...

Powered by blists - more mailing lists