From: syzbot <syzbot+3f66416993279938e957@syzkaller.appspotmail.com>
To: heming.zhao@suse.com, jlbec@evilplan.org,
joseph.qi@linux.alibaba.com, linux-kernel@vger.kernel.org,
mark@fasheh.com, ocfs2-devel@lists.linux.dev,
syzkaller-bugs@googlegroups.com
Subject: [syzbot] [ocfs2?] possible deadlock in ocfs2_duplicate_inline_data
Date: Sat, 14 Nov 2026 00:26:29 -0800 [thread overview]
Message-ID: <6af81b35.097d52ff.3d440.0001.GAE@google.com> (raw)
Hello,
syzbot found the following issue on:
HEAD commit: 97d73c825122 Merge tag 'arm64-fixes' of git://git.kernel.o..
git tree: upstream
console+strace: https://syzkaller.appspot.com/x/log.txt?x=16c6353d580000
kernel config: https://syzkaller.appspot.com/x/.config?x=d16c0eae9c338e3c
dashboard link: https://syzkaller.appspot.com/bug?extid=3f66416993279938e957
compiler: Debian clang version 22.1.8 (1~deb13u4), Debian LLD 22.1.8
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=11c6353d580000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=13609bed580000
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/3968468419c5/disk-97d73c82.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/1066269755a7/vmlinux-97d73c82.xz
kernel image: https://storage.googleapis.com/syzbot-assets/ec6230abb854/bzImage-97d73c82.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/28571daccc92/mount_0.gz
fsck result: OK (log: https://syzkaller.appspot.com/x/fsck.log?x=136fc9ad580000)
AI-generated root cause summary:
In fs/ocfs2/xattr.c, OCFS2_IP_ALLOC_SEM_UNPUBLISHED was defined as 1 to allow
down_write_nested(&OCFS2_I(inode)->ip_alloc_sem, ...) within an active
transaction during inode creation without tripping lockdep against the standard
ip_alloc_sem -> transaction lock order. However, subclass 1
(SINGLE_DEPTH_NESTING) was already in use by ocfs2_remap_file_range() in
fs/ocfs2/file.c when locking the destination inode's ip_alloc_sem. When
ocfs2_remap_file_range() locks the destination inode under subclass 1 and
invokes ocfs2_reflink_remap_blocks() -> ocfs2_duplicate_inline_data(),
ocfs2_start_trans() is called, acquiring sb_internal and j_trans_barrier;
lockdep sees both transaction -> ip_alloc_sem/1 and ip_alloc_sem/1 ->
transaction, reporting a circular locking dependency false positive due to the
subclass collision.
full analysis: https://syzkaller.appspot.com/x/ai_root_cause?x=3f66416993279938e957
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+3f66416993279938e957@syzkaller.appspotmail.com
======================================================
WARNING: possible circular locking dependency detected
syzkaller #0 Not tainted
------------------------------------------------------
syz-executor238/5619 is trying to acquire lock:
ffff88803fb38818 (sb_internal#2){.+.+}-{0:0}, at: ocfs2_duplicate_inline_data+0x16a/0x570 fs/ocfs2/refcounttree.c:3991
but task is already holding lock:
ffff88803559db90 (&oi->ip_alloc_sem/1){+.+.}-{4:4}, at: ocfs2_remap_file_range+0x342/0x700 fs/ocfs2/file.c:2780
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (&oi->ip_alloc_sem/1){+.+.}-{4:4}:
down_write_nested+0x39/0x50 kernel/locking/rwsem.c:1757
ocfs2_xattr_set_handle+0x3fc/0x820 fs/ocfs2/xattr.c:3941
ocfs2_init_security_set+0x151/0x210 fs/ocfs2/xattr.c:7996
ocfs2_mknod+0x13dd/0x2190 fs/ocfs2/namei.c:422
ocfs2_create+0x195/0x460 fs/ocfs2/namei.c:677
lookup_open+0x103d/0x1b00 fs/namei.c:4575
open_last_lookups fs/namei.c:4774 [inline]
path_openat+0x711/0x2100 fs/namei.c:5013
do_file_open+0x23e/0x4a0 fs/namei.c:5045
do_sys_openat2+0x115/0x200 fs/open.c:1443
do_sys_open fs/open.c:1449 [inline]
__do_sys_creat fs/open.c:1527 [inline]
__se_sys_creat fs/open.c:1521 [inline]
__x64_sys_creat+0x8f/0xc0 fs/open.c:1521
do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline]
do_syscall_64+0x16a/0x530 arch/x86/entry/syscall_64.c:89
entry_SYSCALL_64_after_hwframe+0x77/0x7f
-> #1 (&journal->j_trans_barrier){.+.+}-{4:4}:
down_read+0x92/0x200 kernel/locking/rwsem.c:1574
ocfs2_start_trans+0x3aa/0x700 fs/ocfs2/journal.c:379
ocfs2_block_group_alloc fs/ocfs2/suballoc.c:801 [inline]
ocfs2_reserve_suballoc_bits+0x7b7/0x4850 fs/ocfs2/suballoc.c:950
ocfs2_reserve_new_metadata_blocks+0x415/0x9a0 fs/ocfs2/suballoc.c:1100
ocfs2_mknod+0xe79/0x2190 fs/ocfs2/namei.c:350
ocfs2_create+0x195/0x460 fs/ocfs2/namei.c:677
lookup_open+0x103d/0x1b00 fs/namei.c:4575
open_last_lookups fs/namei.c:4774 [inline]
path_openat+0x711/0x2100 fs/namei.c:5013
do_file_open+0x23e/0x4a0 fs/namei.c:5045
do_sys_openat2+0x115/0x200 fs/open.c:1443
do_sys_open fs/open.c:1449 [inline]
__do_sys_creat fs/open.c:1527 [inline]
__se_sys_creat fs/open.c:1521 [inline]
__x64_sys_creat+0x8f/0xc0 fs/open.c:1521
do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline]
do_syscall_64+0x16a/0x530 arch/x86/entry/syscall_64.c:89
entry_SYSCALL_64_after_hwframe+0x77/0x7f
-> #0 (sb_internal#2){.+.+}-{0:0}:
check_prev_add kernel/locking/lockdep.c:3209 [inline]
check_prevs_add kernel/locking/lockdep.c:3328 [inline]
validate_chain kernel/locking/lockdep.c:3952 [inline]
__lock_acquire+0x164c/0x2de0 kernel/locking/lockdep.c:5288
lock_acquire+0x115/0x350 kernel/locking/lockdep.c:5942
percpu_down_read_internal include/linux/percpu-rwsem.h:53 [inline]
percpu_down_read_freezable include/linux/percpu-rwsem.h:83 [inline]
__sb_start_write include/linux/fs/super.h:19 [inline]
sb_start_intwrite include/linux/fs/super.h:177 [inline]
ocfs2_start_trans+0x2a7/0x700 fs/ocfs2/journal.c:377
ocfs2_duplicate_inline_data+0x16a/0x570 fs/ocfs2/refcounttree.c:3991
ocfs2_reflink_remap_blocks+0x4aa/0x1ab0 fs/ocfs2/refcounttree.c:4684
ocfs2_remap_file_range+0x457/0x700 fs/ocfs2/file.c:2788
vfs_copy_file_range+0xe39/0x1430 fs/read_write.c:1581
__do_sys_copy_file_range fs/read_write.c:1664 [inline]
__se_sys_copy_file_range+0x2fb/0x480 fs/read_write.c:1631
do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline]
do_syscall_64+0x16a/0x530 arch/x86/entry/syscall_64.c:89
entry_SYSCALL_64_after_hwframe+0x77/0x7f
other info that might help us debug this:
Chain exists of:
sb_internal#2 --> &journal->j_trans_barrier --> &oi->ip_alloc_sem/1
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&oi->ip_alloc_sem/1);
lock(&journal->j_trans_barrier);
lock(&oi->ip_alloc_sem/1);
rlock(sb_internal#2);
*** DEADLOCK ***
locks held by syz-executor238/5619: 5, on CPU#0:
#0: ffff88803fb38528 (sb_writers#8){.+.+}-{0:0}, at: file_start_write include/linux/fs.h:2765 [inline]
#0: ffff88803fb38528 (sb_writers#8){.+.+}-{0:0}, at: vfs_copy_file_range+0xa29/0x1430 fs/read_write.c:1569
#1: ffff88803559ce80 (&sb->s_type->i_mutex_key#17){+.+.}-{4:4}, at: inode_lock include/linux/fs.h:1027 [inline]
#1: ffff88803559ce80 (&sb->s_type->i_mutex_key#17){+.+.}-{4:4}, at: lock_two_nondirectories+0xe7/0x180 fs/inode.c:1275
#2: ffff88803559df40 (&sb->s_type->i_mutex_key#17/4){+.+.}-{4:4}, at: ocfs2_reflink_inodes_lock+0x11a/0xc20 fs/ocfs2/refcounttree.c:4772
#3: ffff88803559cad0 (&oi->ip_alloc_sem#2){++++}-{4:4}, at: ocfs2_remap_file_range+0x31e/0x700 fs/ocfs2/file.c:2778
#4: ffff88803559db90 (&oi->ip_alloc_sem/1){+.+.}-{4:4}, at: ocfs2_remap_file_range+0x342/0x700 fs/ocfs2/file.c:2780
stack backtrace:
CPU: 0 UID: 0 PID: 5619 Comm: syz-executor238 Not tainted syzkaller #0 PREEMPT_{RT,(full)}
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/06/2026
Call Trace:
<TASK>
dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
print_circular_bug+0x2e2/0x300 kernel/locking/lockdep.c:2087
check_noncircular+0x12f/0x150 kernel/locking/lockdep.c:2219
check_prev_add kernel/locking/lockdep.c:3209 [inline]
check_prevs_add kernel/locking/lockdep.c:3328 [inline]
validate_chain kernel/locking/lockdep.c:3952 [inline]
__lock_acquire+0x164c/0x2de0 kernel/locking/lockdep.c:5288
lock_acquire+0x115/0x350 kernel/locking/lockdep.c:5942
percpu_down_read_internal include/linux/percpu-rwsem.h:53 [inline]
percpu_down_read_freezable include/linux/percpu-rwsem.h:83 [inline]
__sb_start_write include/linux/fs/super.h:19 [inline]
sb_start_intwrite include/linux/fs/super.h:177 [inline]
ocfs2_start_trans+0x2a7/0x700 fs/ocfs2/journal.c:377
ocfs2_duplicate_inline_data+0x16a/0x570 fs/ocfs2/refcounttree.c:3991
ocfs2_reflink_remap_blocks+0x4aa/0x1ab0 fs/ocfs2/refcounttree.c:4684
ocfs2_remap_file_range+0x457/0x700 fs/ocfs2/file.c:2788
vfs_copy_file_range+0xe39/0x1430 fs/read_write.c:1581
__do_sys_copy_file_range fs/read_write.c:1664 [inline]
__se_sys_copy_file_range+0x2fb/0x480 fs/read_write.c:1631
do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline]
do_syscall_64+0x16a/0x530 arch/x86/entry/syscall_64.c:89
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fee8fd74a09
Code: c0 79 93 eb d5 48 8d 7c 1d 00 eb 99 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 d8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffecd787a88 EFLAGS: 00000246 ORIG_RAX: 0000000000000146
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fee8fd74a09
RDX: 0000000000000004 RSI: 0000200000004d40 RDI: 0000000000000005
RBP: 0000000000000001 R08: fffffffffffffff8 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffecd787ac0
R13: 0000000000000002 R14: 431bde82d7b634db R15: 00007fee8fdd404b
</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 syzkaller@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
reply other threads:[~2026-11-14 8:26 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6af81b35.097d52ff.3d440.0001.GAE@google.com \
--to=syzbot+3f66416993279938e957@syzkaller.appspotmail.com \
--cc=heming.zhao@suse.com \
--cc=jlbec@evilplan.org \
--cc=joseph.qi@linux.alibaba.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mark@fasheh.com \
--cc=ocfs2-devel@lists.linux.dev \
--cc=syzkaller-bugs@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.