Re: BUG: MAX_STACK_TRACE_ENTRIES too low! (2)

[Eric Dumazet <eric.dumazet@gmail.com>]

On 7/10/19 8:36 PM, Bart Van Assche wrote:
> On 7/10/19 11:02 AM, Eric Biggers wrote:
>> I already mentioned that io_uring triggers it too.
>>
>> Those are just 2 cases that syzbot happened to generate reproducers for.  I
>> expect there are many others too, since many places in the kernel allocate
>> workqueues.  AFAICS most are placed in static or global variables which avoids
>> this issue, but there are still many cases where a workqueue is owned by some
>> dynamic structure that can have a much shorter lifetime.
>>
>> You can also check the other syzbot reports that look similar
>> (https://lore.kernel.org/lkml/20190710055838.GC2152@sol.localdomain/).
>> Two of them have C reproducers too.
> 
> As you may know lockdep cannot use dynamic memory allocation because
> doing so would introduce a circular dependency between lockdep and the
> memory allocator. Hence the fixed size arrays in the lockdep code.
> Additionally, as far as I know lockdep works fine for human kernel
> developers and only syzbot runs code that triggers the lockdep limits.
> So I think it's up to the syzbot authors to come up with a solution. I
> mean another solution than finger pointing at kernel developers.

This is silly, syzbot simply uses kernel standard system calls.

If anything using workqueues in dynamically allocated objects can turn off lockdep,
we have a serious issue.

Please work on this issue instead of trying to blame someone else.

Thank you.