[syzbot] [fs?] INFO: trying to register non-static key in debugfs_file_get

7 views
Skip to first unread message

syzbot

unread,
Dec 21, 2023, 8:35:25 AM12/21/23
to gre...@linuxfoundation.org, linux-...@vger.kernel.org, linux-...@vger.kernel.org, raf...@kernel.org, syzkall...@googlegroups.com
Hello,

syzbot found the following issue on:

HEAD commit: b10a3ccaf6e3 Merge tag 'loongarch-fixes-6.7-2' of git://gi..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1278f06ce80000
kernel config: https://syzkaller.appspot.com/x/.config?x=70dcde26e6b912e5
dashboard link: https://syzkaller.appspot.com/bug?extid=fb20af23d0671a82c9a2
compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40

Unfortunately, I don't have any reproducer for this issue yet.

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/ee4bb72d1747/disk-b10a3cca.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/35219c49fd40/vmlinux-b10a3cca.xz
kernel image: https://storage.googleapis.com/syzbot-assets/d3c8dc8aa792/bzImage-b10a3cca.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+fb20af...@syzkaller.appspotmail.com

INFO: trying to register non-static key.
The code is fine but needs lockdep annotation, or maybe
you didn't initialize this object before use?
turning off the locking correctness validator.
CPU: 0 PID: 5078 Comm: syz-executor.0 Not tainted 6.7.0-rc4-syzkaller-00384-gb10a3ccaf6e3 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106
assign_lock_key+0x234/0x270 kernel/locking/lockdep.c:976
register_lock_class+0x1cf/0x970 kernel/locking/lockdep.c:1289
__lock_acquire+0xd9/0x1fd0 kernel/locking/lockdep.c:5014
lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754
debugfs_file_get+0x545/0x6d0 fs/debugfs/file.c:135
open_proxy_open+0x56/0x490 fs/debugfs/file.c:269
do_dentry_open+0x8ff/0x1590 fs/open.c:948
do_open fs/namei.c:3622 [inline]
path_openat+0x2849/0x3290 fs/namei.c:3779
do_filp_open+0x234/0x490 fs/namei.c:3809
do_sys_openat2+0x13e/0x1d0 fs/open.c:1440
do_sys_open fs/open.c:1455 [inline]
__do_sys_openat fs/open.c:1471 [inline]
__se_sys_openat fs/open.c:1466 [inline]
__x64_sys_openat+0x247/0x290 fs/open.c:1466
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0x45/0x110 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x63/0x6b
RIP: 0033:0x7f8cf7a7b721
Code: 75 57 89 f0 25 00 00 41 00 3d 00 00 41 00 74 49 80 3d ea 17 10 00 00 74 6d 89 da 48 89 ee bf 9c ff ff ff b8 01 01 00 00 0f 05 <48> 3d 00 f0 ff ff 0f 87 93 00 00 00 48 8b 54 24 28 64 48 2b 14 25
RSP: 002b:00007ffe0eccf310 EFLAGS: 00000202 ORIG_RAX: 0000000000000101
RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f8cf7a7b721
RDX: 0000000000000002 RSI: 00007f8cf7ac7551 RDI: 00000000ffffff9c
RBP: 00007f8cf7ac7551 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000202 R12: 00007ffe0eccfa68
R13: 0000000000000003 R14: 00007f8cf7b9c018 R15: 0000000000000000
</TASK>


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzk...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

Tetsuo Handa

unread,
Dec 21, 2023, 8:53:13 AM12/21/23
to syzbot, Greg Kroah-Hartman, Johannes Berg, syzkall...@googlegroups.com, linux-...@vger.kernel.org, linux-...@vger.kernel.org, raf...@kernel.org
#syz fix: Revert "debugfs: annotate debugfs handlers vs. removal with lockdep"

By the way, use of cmpxchg() implies that this path might run in parallel?
If yes, I think you need to finish lockdep_init_map() before cmpxchg(), or
concurrently running threads might reach lock_map_acquire_read() before
lockdep_init_map() completes...

d_fsd = READ_ONCE(dentry->d_fsdata);
if (!((unsigned long)d_fsd & DEBUGFS_FSDATA_IS_REAL_FOPS_BIT)) {
fsd = d_fsd;
} else {
fsd = kmalloc(sizeof(*fsd), GFP_KERNEL);
if (!fsd)
return -ENOMEM;

fsd->real_fops = (void *)((unsigned long)d_fsd &
~DEBUGFS_FSDATA_IS_REAL_FOPS_BIT);
refcount_set(&fsd->active_users, 1);
init_completion(&fsd->active_users_drained);
if (cmpxchg(&dentry->d_fsdata, d_fsd, fsd) != d_fsd) {
kfree(fsd);
fsd = READ_ONCE(dentry->d_fsdata);
}
+#ifdef CONFIG_LOCKDEP
+ fsd->lock_name = kasprintf(GFP_KERNEL, "debugfs:%pd", dentry);
+ lockdep_register_key(&fsd->key);
+ lockdep_init_map(&fsd->lockdep_map, fsd->lock_name ?: "debugfs",
+ &fsd->key, 0);
+#endif
}

/*
* In case of a successful cmpxchg() above, this check is
* strictly necessary and must follow it, see the comment in
* __debugfs_remove_file().
* OTOH, if the cmpxchg() hasn't been executed or wasn't
* successful, this serves the purpose of not starving
* removers.
*/
if (d_unlinked(dentry))
return -EIO;

if (!refcount_inc_not_zero(&fsd->active_users))
return -EIO;

+ lock_map_acquire_read(&fsd->lockdep_map);
Reply all
Reply to author
Forward
0 new messages