From: Bart Van Assche
Date: Wed Jul 10 2019 - 10:20:00 EST

On 7/9/19 10:30 PM, Eric Biggers wrote:
[Moved most people to Bcc; syzbot added way too many random people to this.]

Hi Bart,

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:

commit 669de8bda87b92ab9a2fc663b3f5743c2ad1ae9f
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:Â
start commit:ÂÂ 0e40da3e Merge tag 'kbuild-fixes-v5.1' of
git tree:ÂÂÂÂÂÂ upstream
final crash:ÂÂÂ
console output:
kernel config:Â
dashboard link:
syz repro:ÂÂÂÂÂ
C reproducer:ÂÂ

Reported-by: syzbot+6f39a9deb697359fe520@xxxxxxxxxxxxxxxxxxxxxxxxx
Fixes: 669de8bda87b ("kernel/workqueue: Use dynamic lockdep keys for

For information about bisection process see:

Hi Dmitry,

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:

Am I understanding it correctly? How did you intend this to work?

The last two paragraphs do not make sense to me. My changes do not increase the number of stack traces that get recorded by the lockdep code.