linux-kernel - 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-next>] [day] [month] [year] [list]

Date:   Tue, 26 Jul 2022 17:32:54 +0500
From:   Mikhail Gavrilov <mikhail.v.gavrilov@...il.com>
To:     Btrfs BTRFS <linux-btrfs@...r.kernel.org>,
        Linux List Kernel Mailing <linux-kernel@...r.kernel.org>
Subject: BUG: MAX_LOCKDEP_CHAIN_HLOCKS too low!

Hi guys.
Always with intensive writing on a btrfs volume, the message "BUG:
MAX_LOCKDEP_CHAIN_HLOCKS too low!" appears in the kernel logs.

[46729.134549] BUG: MAX_LOCKDEP_CHAIN_HLOCKS too low!
[46729.134557] turning off the locking correctness validator.
[46729.134559] Please attach the output of /proc/lock_stat to the bug report
[46729.134561] CPU: 22 PID: 166516 Comm: ThreadPoolForeg Tainted: G
    W    L   --------  ---
5.19.0-0.rc7.20220722git68e77ffbfd06.56.fc37.x86_64 #1
[46729.134566] Hardware name: System manufacturer System Product
Name/ROG STRIX X570-I GAMING, BIOS 4403 04/27/2022
[46729.134569] Call Trace:
[46729.134572]  <TASK>
[46729.134576]  dump_stack_lvl+0x5b/0x77
[46729.134583]  __lock_acquire.cold+0x167/0x29e
[46729.134594]  lock_acquire+0xce/0x2d0
[46729.134599]  ? btrfs_reserve_extent+0xbd/0x250
[46729.134606]  ? btrfs_get_alloc_profile+0x17e/0x240
[46729.134611]  btrfs_get_alloc_profile+0x19c/0x240
[46729.134614]  ? btrfs_reserve_extent+0xbd/0x250
[46729.134618]  btrfs_reserve_extent+0xbd/0x250
[46729.134629]  btrfs_alloc_tree_block+0xa3/0x510
[46729.134635]  ? release_extent_buffer+0xa7/0xe0
[46729.134643]  split_node+0x131/0x3d0
[46729.134652]  btrfs_search_slot+0x2f3/0xc30
[46729.134659]  ? btrfs_insert_inode_ref+0x50/0x3b0
[46729.134664]  btrfs_insert_empty_items+0x31/0x70
[46729.134669]  btrfs_insert_inode_ref+0x99/0x3b0
[46729.134678]  btrfs_rename2+0x317/0x1510
[46729.134690]  ? vfs_rename+0x49d/0xd20
[46729.134693]  ? btrfs_symlink+0x460/0x460
[46729.134696]  vfs_rename+0x49d/0xd20
[46729.134705]  ? do_renameat2+0x4a0/0x510
[46729.134709]  do_renameat2+0x4a0/0x510
[46729.134720]  __x64_sys_rename+0x3f/0x50
[46729.134724]  do_syscall_64+0x5b/0x80
[46729.134729]  ? memcg_slab_free_hook+0x1fd/0x2e0
[46729.134735]  ? do_faccessat+0x111/0x260
[46729.134739]  ? kmem_cache_free+0x379/0x3d0
[46729.134744]  ? lock_is_held_type+0xe8/0x140
[46729.134749]  ? do_syscall_64+0x67/0x80
[46729.134752]  ? lockdep_hardirqs_on+0x7d/0x100
[46729.134757]  ? do_syscall_64+0x67/0x80
[46729.134760]  ? asm_exc_page_fault+0x22/0x30
[46729.134764]  ? lockdep_hardirqs_on+0x7d/0x100
[46729.134768]  entry_SYSCALL_64_after_hwframe+0x63/0xcd
[46729.134773] RIP: 0033:0x7fd2a29b5afb
[46729.134798] Code: e8 7a 27 0a 00 f7 d8 19 c0 5b c3 0f 1f 40 00 b8
ff ff ff ff 5b c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa b8 52 00 00
00 0f 05 <48> 3d 00 f0 ff ff 77 05 c3 0f 1f 40 00 48 8b 15 f1 82 17 00
f7 d8
[46729.134801] RSP: 002b:00007fd25b70a5a8 EFLAGS: 00000282 ORIG_RAX:
0000000000000052
[46729.134805] RAX: ffffffffffffffda RBX: 00007fd25b70a5e0 RCX: 00007fd2a29b5afb
[46729.134808] RDX: 0000000000000000 RSI: 00003ba01ef60820 RDI: 00003ba00e4b2da0
[46729.134810] RBP: 00007fd25b70a660 R08: 0000000000000000 R09: 00007fd25b70a570
[46729.134812] R10: 00007ffd36b1f080 R11: 0000000000000282 R12: 00007fd25b70a5b8
[46729.134815] R13: 00003ba00e4b2da0 R14: 00007fd25b70a6c4 R15: 00003ba01ef60820
[46729.134823]  </TASK>

In this regard, I want to ask, is this really a bug?
The kernel version is 5.19-rc7.

Here's the full kernel log: https://pastebin.com/hYWH7RHu
Here's /proc/lock_stat: https://pastebin.com/ex5w0QW9

-- 
Best Regards,
Mike Gavrilov.