From: syzbot <syzbot+13eb8132f7693fe21d7d@syzkaller.appspotmail.com>
To: bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com,
linux-kernel@vger.kernel.org, linux-raid@vger.kernel.org,
magiclinan@didiglobal.com, mingo@redhat.com, song@kernel.org,
syzkaller-bugs@googlegroups.com, tglx@kernel.org,
x86@kernel.org, xiao@kernel.org, yukuai@fnnas.com,
yukuai@fygo.io
Subject: Re: [syzbot] [kernel?] possible deadlock in md_start_sync
Date: Mon, 14 Sep 2026 14:21:41 -0700 [thread overview]
Message-ID: <6aa86565.f670cee1.72fc4.0021.GAE@google.com> (raw)
In-Reply-To: <6a6e88a1.13bfb6d0.1ecdd5.0261.GAE@google.com>
syzbot has found a reproducer for the following issue on:
HEAD commit: 704340f1cd0d Merge tag 'x86_urgent_for_7.3-rc4' of git://g..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=14051925580000
kernel config: https://syzkaller.appspot.com/x/.config?x=8c5c3949d762a91f
dashboard link: https://syzkaller.appspot.com/bug?extid=13eb8132f7693fe21d7d
compiler: gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12a5bdf9580000
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/192c594c6096/disk-704340f1.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/79d1488deb4b/vmlinux-704340f1.xz
kernel image: https://storage.googleapis.com/syzbot-assets/fd108c2b8ca0/bzImage-704340f1.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+13eb8132f7693fe21d7d@syzkaller.appspotmail.com
======================================================
WARNING: possible circular locking dependency detected
syzkaller #0 Not tainted
------------------------------------------------------
kworker/0:0/9 is trying to acquire lock:
ffff888026076358 (&mddev->reconfig_mutex){+.+.}-{4:4}, at: mddev_lock_nointr drivers/md/md.h:734 [inline]
ffff888026076358 (&mddev->reconfig_mutex){+.+.}-{4:4}, at: md_start_sync+0xc4/0xea0 drivers/md/md.c:10275
but task is already holding lock:
ffffc900000e7d08 ((work_completion)(&mddev->sync_work)){+.+.}-{0:0}, at: process_one_work+0xa2c/0x1b10 kernel/workqueue.c:3372
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #3 ((work_completion)(&mddev->sync_work)){+.+.}-{0:0}:
lock_acquire kernel/locking/lockdep.c:5942 [inline]
lock_acquire+0x1d1/0x380 kernel/locking/lockdep.c:5899
process_one_work+0xa32/0x1b10 kernel/workqueue.c:3372
process_scheduled_works kernel/workqueue.c:3479 [inline]
worker_thread+0x5ef/0xe50 kernel/workqueue.c:3560
kthread+0x373/0x450 kernel/kthread.c:436
ret_from_fork+0x730/0xd60 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
-> #2 ((wq_completion)md_misc){+.+.}-{0:0}:
lock_acquire kernel/locking/lockdep.c:5942 [inline]
lock_acquire+0x1d1/0x380 kernel/locking/lockdep.c:5899
touch_wq_lockdep_map+0xad/0x1c0 kernel/workqueue.c:4111
__flush_workqueue+0x131/0x1200 kernel/workqueue.c:4153
md_alloc+0x30/0x10a0 drivers/md/md.c:6334
md_alloc_and_put drivers/md/md.c:6423 [inline]
md_probe drivers/md/md.c:6439 [inline]
md_probe+0x73/0xf0 drivers/md/md.c:6434
blk_probe_dev+0x149/0x1e0 block/genhd.c:888
blk_request_module+0x16/0xc0 block/genhd.c:901
blkdev_get_no_open+0x9b/0xf0 block/bdev.c:870
blkdev_open+0x141/0x4f0 block/fops.c:665
do_dentry_open+0x6ab/0x14d0 fs/open.c:996
vfs_open+0x82/0x3f0 fs/open.c:1101
do_open fs/namei.c:4837 [inline]
path_openat+0x19fa/0x2440 fs/namei.c:5000
do_file_open+0x20e/0x430 fs/namei.c:5029
do_sys_openat2+0x10f/0x1e0 fs/open.c:1417
do_sys_open fs/open.c:1423 [inline]
__do_sys_openat fs/open.c:1439 [inline]
__se_sys_openat fs/open.c:1434 [inline]
__x64_sys_openat+0x12d/0x210 fs/open.c:1434
do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline]
do_syscall_64+0x123/0x790 arch/x86/entry/syscall_64.c:84
entry_SYSCALL_64_after_hwframe+0x77/0x7f
-> #1 (major_names_lock){+.+.}-{4:4}:
lock_acquire kernel/locking/lockdep.c:5942 [inline]
lock_acquire+0x1d1/0x380 kernel/locking/lockdep.c:5899
__mutex_lock_common kernel/locking/mutex.c:646 [inline]
__mutex_lock+0x1a4/0x1bd0 kernel/locking/mutex.c:821
blk_probe_dev+0x28/0x1e0 block/genhd.c:885
blk_request_module+0x16/0xc0 block/genhd.c:901
blkdev_get_no_open+0x9b/0xf0 block/bdev.c:870
bdev_file_open_by_dev block/bdev.c:1091 [inline]
bdev_file_open_by_dev+0x70/0x210 block/bdev.c:1079
md_import_device+0x120/0x360 drivers/md/md.c:3847
md_add_new_disk+0xdbf/0x1820 drivers/md/md.c:7656
md_ioctl+0x2bec/0x36d0 drivers/md/md.c:8499
blkdev_ioctl+0x5ad/0x6f0 block/ioctl.c:798
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:597 [inline]
__se_sys_ioctl fs/ioctl.c:583 [inline]
__x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:583
do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline]
do_syscall_64+0x123/0x790 arch/x86/entry/syscall_64.c:84
entry_SYSCALL_64_after_hwframe+0x77/0x7f
-> #0 (&mddev->reconfig_mutex){+.+.}-{4:4}:
check_prev_add+0xeb/0xe60 kernel/locking/lockdep.c:3209
check_prevs_add kernel/locking/lockdep.c:3328 [inline]
validate_chain kernel/locking/lockdep.c:3952 [inline]
__lock_acquire+0x1528/0x1f40 kernel/locking/lockdep.c:5288
lock_acquire kernel/locking/lockdep.c:5942 [inline]
lock_acquire+0x1d1/0x380 kernel/locking/lockdep.c:5899
__mutex_lock_common kernel/locking/mutex.c:646 [inline]
__mutex_lock+0x1a4/0x1bd0 kernel/locking/mutex.c:821
mddev_lock_nointr drivers/md/md.h:734 [inline]
md_start_sync+0xc4/0xea0 drivers/md/md.c:10275
process_one_work+0xac7/0x1b10 kernel/workqueue.c:3396
process_scheduled_works kernel/workqueue.c:3479 [inline]
worker_thread+0x5ef/0xe50 kernel/workqueue.c:3560
kthread+0x373/0x450 kernel/kthread.c:436
ret_from_fork+0x730/0xd60 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
other info that might help us debug this:
Chain exists of:
&mddev->reconfig_mutex --> (wq_completion)md_misc --> (work_completion)(&mddev->sync_work)
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock((work_completion)(&mddev->sync_work));
lock((wq_completion)md_misc);
lock((work_completion)(&mddev->sync_work));
lock(&mddev->reconfig_mutex);
*** DEADLOCK ***
locks held by kworker/0:0/9: 2, last CPU#0:
#0: ffff88801fadf140 ((wq_completion)md_misc){+.+.}-{0:0}, at: process_one_work+0x1466/0x1b10 kernel/workqueue.c:3371
#1: ffffc900000e7d08 ((work_completion)(&mddev->sync_work)){+.+.}-{0:0}, at: process_one_work+0xa2c/0x1b10 kernel/workqueue.c:3372
stack backtrace:
CPU: 0 UID: 0 PID: 9 Comm: kworker/0:0 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/05/2026
Workqueue: md_misc md_start_sync
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120
print_circular_bug.cold+0x178/0x1be kernel/locking/lockdep.c:2087
check_noncircular+0x146/0x160 kernel/locking/lockdep.c:2219
check_prev_add+0xeb/0xe60 kernel/locking/lockdep.c:3209
check_prevs_add kernel/locking/lockdep.c:3328 [inline]
validate_chain kernel/locking/lockdep.c:3952 [inline]
__lock_acquire+0x1528/0x1f40 kernel/locking/lockdep.c:5288
lock_acquire kernel/locking/lockdep.c:5942 [inline]
lock_acquire+0x1d1/0x380 kernel/locking/lockdep.c:5899
__mutex_lock_common kernel/locking/mutex.c:646 [inline]
__mutex_lock+0x1a4/0x1bd0 kernel/locking/mutex.c:821
mddev_lock_nointr drivers/md/md.h:734 [inline]
md_start_sync+0xc4/0xea0 drivers/md/md.c:10275
process_one_work+0xac7/0x1b10 kernel/workqueue.c:3396
process_scheduled_works kernel/workqueue.c:3479 [inline]
worker_thread+0x5ef/0xe50 kernel/workqueue.c:3560
kthread+0x373/0x450 kernel/kthread.c:436
ret_from_fork+0x730/0xd60 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
</TASK>
---
If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.
next prev parent reply other threads:[~2026-09-14 21:21 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-02 0:00 [syzbot] [raid?] possible deadlock in md_start_sync syzbot
2026-09-14 21:21 ` syzbot [this message]
2026-10-14 16:19 ` [syzbot] [kernel?] " syzbot
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=6aa86565.f670cee1.72fc4.0021.GAE@google.com \
--to=syzbot+13eb8132f7693fe21d7d@syzkaller.appspotmail.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-raid@vger.kernel.org \
--cc=magiclinan@didiglobal.com \
--cc=mingo@redhat.com \
--cc=song@kernel.org \
--cc=syzkaller-bugs@googlegroups.com \
--cc=tglx@kernel.org \
--cc=x86@kernel.org \
--cc=xiao@kernel.org \
--cc=yukuai@fnnas.com \
--cc=yukuai@fygo.io \
/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.