linux-kernel - Re: BUG: MAX_LOCKDEP_CHAIN

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]

Message-ID: <CABXGCsMa-BUWx4Xwc0nBKvSwPdX4HJXf=kZZOndYmNQNELx02g@mail.gmail.com>
Date: Tue, 23 Sep 2025 12:03:24 +0500
From: Mikhail Gavrilov <mikhail.v.gavrilov@...il.com>
To: Boqun Feng <boqun.feng@...il.com>
Cc: Peter Zijlstra <peterz@...radead.org>, dsterba@...e.cz, 
	Btrfs BTRFS <linux-btrfs@...r.kernel.org>, 
	Linux List Kernel Mailing <linux-kernel@...r.kernel.org>, Chris Murphy <lists@...orremedies.com>, 
	Ingo Molnar <mingo@...hat.com>, Will Deacon <will@...nel.org>, Waiman Long <longman@...hat.com>, 
	Joel Fernandes <joel@...lfernandes.org>
Subject: Re: BUG: MAX_LOCKDEP_CHAIN_HLOCKS too low!

On Mon, Mar 10, 2025 at 9:38 PM Boqun Feng <boqun.feng@...il.com> wrote:
>
>
>
> No reason we cannot move the check_wait_context() before nesting
> handling, right?
>
> diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
> index 4470680f0226..67c0a68eee6b 100644
> --- a/kernel/locking/lockdep.c
> +++ b/kernel/locking/lockdep.c
> @@ -5129,28 +5129,6 @@ static int __lock_acquire(struct lockdep_map *lock, unsigned int subclass,
>         if (DEBUG_LOCKS_WARN_ON(depth >= MAX_LOCK_DEPTH))
>                 return 0;
>
> -       class_idx = class - lock_classes;
> -
> -       if (depth && !sync) {
> -               /* we're holding locks and the new held lock is not a sync */
> -               hlock = curr->held_locks + depth - 1;
> -               if (hlock->class_idx == class_idx && nest_lock) {
> -                       if (!references)
> -                               references++;
> -
> -                       if (!hlock->references)
> -                               hlock->references++;
> -
> -                       hlock->references += references;
> -
> -                       /* Overflow */
> -                       if (DEBUG_LOCKS_WARN_ON(hlock->references < references))
> -                               return 0;
> -
> -                       return 2;
> -               }
> -       }
> -
>         hlock = curr->held_locks + depth;
>         /*
>          * Plain impossible, we just registered it and checked it weren't no
> @@ -5178,6 +5156,28 @@ static int __lock_acquire(struct lockdep_map *lock, unsigned int subclass,
>         if (check_wait_context(curr, hlock))
>                 return 0;
>
> +       class_idx = class - lock_classes;
> +
> +       if (depth && !sync) {
> +               /* we're holding locks and the new held lock is not a sync */
> +               hlock = curr->held_locks + depth - 1;
> +               if (hlock->class_idx == class_idx && nest_lock) {
> +                       if (!references)
> +                               references++;
> +
> +                       if (!hlock->references)
> +                               hlock->references++;
> +
> +                       hlock->references += references;
> +
> +                       /* Overflow */
> +                       if (DEBUG_LOCKS_WARN_ON(hlock->references < references))
> +                               return 0;
> +
> +                       return 2;
> +               }
> +       }
> +
>         /* Initialize the lock usage bit */
>         if (!mark_usage(curr, hlock, check))
>                 return 0;
>
>

Sorry, I’ve been quite busy.
The BUG: MAX_STACK_TRACE_ENTRIES too low occurs every single day.
I can test any patch for 6.17.0-0.rc7 that may mitigate this issue.
Thanks.


-- 
Best Regards,
Mike Gavrilov.

View attachment "dmesg-MAX_STACK_TRACE_ENTRIES-too-low-36.txt" of type "text/plain" (261722 bytes)

View attachment "lock_stat-36.txt" of type "text/plain" (1008197 bytes)