Re: WARNING in percpu_ref_kill_and_confirm
From: Dmitry Vyukov
Date: Tue Apr 23 2019 - 10:41:55 EST
On Mon, Apr 22, 2019 at 7:48 PM Linus Torvalds
> On Mon, Apr 22, 2019 at 9:38 AM Jens Axboe <axboe@xxxxxxxxx> 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!
> 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...