linux-kernel - Re: BUG: MAX_LOCKDEP_ENTRIES too low! triggered by ext4&workqueue

lists.openwall.net		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 linux-hardening linux-cve-announce 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: Thu, 14 Mar 2024 07:22:54 +0000
From: Weiß, Simone <Simone.Weiss@...ktrobit.com>
To: "tj@...nel.org" <tj@...nel.org>
CC: "jiangshanlai@...il.com" <jiangshanlai@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: BUG: MAX_LOCKDEP_ENTRIES too low! triggered by ext4&workqueue

On Wed, 2024-03-13 at 10:09 -1000, tj@...nel.org wrote:
> On Wed, Mar 13, 2024 at 12:15:24PM +0000, Weiß, Simone wrote:
> > Dear all,
> > 
> > For some experimentation, I have been running fuzzing campaigns and I
> > noticed  BUG: MAX_LOCKDEP_ENTRIES too low! most likely triggered by ext4
> > operations.
> > 
> > As I found a C reproducer in my setup, it could be bisected being introduced
> > with the following:
> > commit 967b494e2fd143a9c1a3201422aceadb5fa9fbfc
> > Author: Tejun Heo <tj@...nel.org>
> > Date:   Mon Aug 7 15:57:23 2023 -1000
> > 
> >     workqueue: Use a kthread_worker to release pool_workqueues
> > 
> >     pool_workqueue release path is currently bounced to system_wq; however,
> > this
> >     is a bit tricky because this bouncing occurs while holding a pool lock
> > and
> >     thus has risk of causing a A-A deadlock. This is currently addressed by
> > the
> >     fact that only unbound workqueues use this bouncing path and system_wq
> > is a
> >     per-cpu workqueue.
> > 
> > ...
> > 
> > It was reproducible on v6.6.16 and v6.16.21.
> > The C reproducer is automatically generated by syzkaller and included below.
> > 
> > If you need any further information, just let me know.
> 
> Does the following happen to fix the issue for you?
> 
> Thanks.
> 
> diff --git a/kernel/locking/lockdep_internals.h
> b/kernel/locking/lockdep_internals.h
> index bbe9000260d0..bc027ea2372b 100644
> --- a/kernel/locking/lockdep_internals.h
> +++ b/kernel/locking/lockdep_internals.h
> @@ -94,7 +94,7 @@ static const unsigned long LOCKF_USED_IN_IRQ_READ =
>   * table (if it's not there yet), and we check it for lock order
>   * conflicts and deadlocks.
>   */
> -#define MAX_LOCKDEP_ENTRIES    16384UL
> +#define MAX_LOCKDEP_ENTRIES    32768UL
>  #define MAX_LOCKDEP_CHAINS_BITS        15
>  #define MAX_STACK_TRACE_ENTRIES        262144UL
>  #define STACK_TRACE_HASH_SIZE  8192
> 
> --
> tejun
Hello,

I applied the diff on v6.8 and could still reproduce the issue.
As I understand the code, this would only been taken in if
CONFIG_LOCKDEP_SMALL is set. Lockdep related config options on
my side are:

CONFIG_LOCKDEP_SUPPORT=y
CONFIG_LOCKDEP=y
CONFIG_LOCKDEP_BITS=15
CONFIG_LOCKDEP_CHAINS_BITS=16
CONFIG_LOCKDEP_STACK_TRACE_BITS=19
CONFIG_LOCKDEP_STACK_TRACE_HASH_BITS=14
CONFIG_LOCKDEP_CIRCULAR_QUEUE_BITS=12
# CONFIG_DEBUG_LOCKDEP is not set

Thanks,
Simone