[Moved most people to Bcc; syzbot added way too many random people to this.]
On Sat, Mar 30, 2019 at 07:17:09PM -0700, Bart Van Assche wrote:
On 3/30/19 2:58 PM, syzbot wrote:
syzbot has bisected this bug to:
Author: Bart Van Assche <bvanassche@xxxxxxx>
Date:ÂÂ Thu Feb 14 23:00:54 2019 +0000
ÂÂÂ kernel/workqueue: Use dynamic lockdep keys for workqueues
bisection log:Â https://syzkaller.appspot.com/x/bisect.txt?x=17f1bacd200000
start commit:ÂÂ 0e40da3e Merge tag 'kbuild-fixes-v5.1' of
git tree:ÂÂÂÂÂÂ upstream
final crash:ÂÂÂ https://syzkaller.appspot.com/x/report.txt?x=1409bacd200000
console output: https://syzkaller.appspot.com/x/log.txt?x=1009bacd200000
kernel config:Â https://syzkaller.appspot.com/x/.config?x=8dcdce25ea72bedf
syz repro:ÂÂÂÂÂ https://syzkaller.appspot.com/x/repro.syz?x=10e1bacd200000
C reproducer:ÂÂ https://syzkaller.appspot.com/x/repro.c?x=1120fe0f200000
Fixes: 669de8bda87b ("kernel/workqueue: Use dynamic lockdep keys for
For information about bisection process see:
This bisection result doesn't make sense to me. As one can see, the message
"BUG: MAX_STACK_TRACE_ENTRIES too low!" does not occur in the console output
the above console output URL points at.
This is still happening on mainline, and I think this bisection result is
probably correct. syzbot did start hitting something different at the very end
of the bisection ("WARNING: CPU: 0 PID: 9153 at kernel/locking/lockdep.c:747")
but that seems to be just because your commit had a lot of bugs in it, which had
to be fixed by later commits. In particular, the WARNING seems to have been
fixed by commit 28d49e282665e ("locking/lockdep: Shrink struct lock_class_key").
What seems to still be happening is that the dynamic lockdep keys which you
added make it possible for an unbounded number of entries to be added to the
fixed length stack_trace array in kernel/locking/lockdep.c. Hence the "BUG:
MAX_STACK_TRACE_ENTRIES too low!".
Am I understanding it correctly? How did you intend this to work?