From: syzbot ci <syzbot+ci3c65cfe4c9a15aea@syzkaller.appspotmail.com>
To: akpm@linux-foundation.org, bhe@redhat.com,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
lirongqing@baidu.com, urezki@gmail.com
Cc: syzbot@lists.linux.dev, syzkaller-bugs@googlegroups.com
Subject: [syzbot ci] Re: mm/vmalloc: Use dedicated unbound workqueue for vmap purge/drain
Date: Tue, 31 Mar 2026 00:42:03 -0700 [thread overview]
Message-ID: <69cb7acb.050a0220.183828.0025.GAE@google.com> (raw)
In-Reply-To: <20260330175824.2777270-1-urezki@gmail.com>
syzbot ci has tested the following series
[v2] mm/vmalloc: Use dedicated unbound workqueue for vmap purge/drain
https://lore.kernel.org/all/20260330175824.2777270-1-urezki@gmail.com
* [PATCH v2] mm/vmalloc: Use dedicated unbound workqueue for vmap purge/drain
and found the following issue:
possible deadlock in touch_wq_lockdep_map
Full report is available here:
https://ci.syzbot.org/series/4a8f638e-3a3f-4346-8189-2b5a0eb9ceaf
***
possible deadlock in touch_wq_lockdep_map
tree: mm-new
URL: https://kernel.googlesource.com/pub/scm/linux/kernel/git/akpm/mm.git
base: af42d6d3650b95295a3f08fc35189998bc26c2e1
arch: amd64
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
config: https://ci.syzbot.org/builds/d94b1f61-6a69-4415-b385-b3c99018e8c2/config
syz repro: https://ci.syzbot.org/findings/01e4d436-e924-4ce6-8902-78c6000bf34e/syz_repro
============================================
WARNING: possible recursive locking detected
syzkaller #0 Not tainted
--------------------------------------------
kworker/u9:1/33 is trying to acquire lock:
ffff88810168e948 ((wq_completion)vmap_drain){+.+.}-{0:0}, at: touch_wq_lockdep_map+0xb5/0x180 kernel/workqueue.c:3991
but task is already holding lock:
ffff88810168e948 ((wq_completion)vmap_drain){+.+.}-{0:0}, at: process_one_work kernel/workqueue.c:3251 [inline]
ffff88810168e948 ((wq_completion)vmap_drain){+.+.}-{0:0}, at: process_scheduled_works+0xa52/0x18c0 kernel/workqueue.c:3359
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock((wq_completion)vmap_drain);
lock((wq_completion)vmap_drain);
*** DEADLOCK ***
May be due to missing lock nesting notation
4 locks held by kworker/u9:1/33:
#0: ffff88810168e948 ((wq_completion)vmap_drain){+.+.}-{0:0}, at: process_one_work kernel/workqueue.c:3251 [inline]
#0: ffff88810168e948 ((wq_completion)vmap_drain){+.+.}-{0:0}, at: process_scheduled_works+0xa52/0x18c0 kernel/workqueue.c:3359
#1: ffffc90000a97c40 (drain_vmap_work){+.+.}-{0:0}, at: process_one_work kernel/workqueue.c:3252 [inline]
#1: ffffc90000a97c40 (drain_vmap_work){+.+.}-{0:0}, at: process_scheduled_works+0xa8d/0x18c0 kernel/workqueue.c:3359
#2: ffffffff8e87ed68 (vmap_purge_lock){+.+.}-{4:4}, at: drain_vmap_area_work+0x17/0x40 mm/vmalloc.c:2443
#3: ffffffff8e75e5e0 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:312 [inline]
#3: ffffffff8e75e5e0 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:850 [inline]
#3: ffffffff8e75e5e0 (rcu_read_lock){....}-{1:3}, at: start_flush_work kernel/workqueue.c:4234 [inline]
#3: ffffffff8e75e5e0 (rcu_read_lock){....}-{1:3}, at: __flush_work+0x100/0xc50 kernel/workqueue.c:4292
stack backtrace:
CPU: 1 UID: 0 PID: 33 Comm: kworker/u9:1 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
Workqueue: vmap_drain drain_vmap_area_work
Call Trace:
<TASK>
dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
print_deadlock_bug+0x279/0x290 kernel/locking/lockdep.c:3041
check_deadlock kernel/locking/lockdep.c:3093 [inline]
validate_chain kernel/locking/lockdep.c:3895 [inline]
__lock_acquire+0x253f/0x2cf0 kernel/locking/lockdep.c:5237
lock_acquire+0xf0/0x2e0 kernel/locking/lockdep.c:5868
touch_wq_lockdep_map+0xcb/0x180 kernel/workqueue.c:3991
start_flush_work kernel/workqueue.c:4272 [inline]
__flush_work+0x87c/0xc50 kernel/workqueue.c:4292
__purge_vmap_area_lazy+0x7db/0xab0 mm/vmalloc.c:2419
drain_vmap_area_work+0x27/0x40 mm/vmalloc.c:2444
process_one_work kernel/workqueue.c:3276 [inline]
process_scheduled_works+0xb6e/0x18c0 kernel/workqueue.c:3359
worker_thread+0xa53/0xfc0 kernel/workqueue.c:3440
kthread+0x388/0x470 kernel/kthread.c:436
ret_from_fork+0x51e/0xb90 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
</TASK>
***
If these findings have caused you to resend the series or submit a
separate fix, please add the following tag to your commit message:
Tested-by: syzbot@syzkaller.appspotmail.com
---
This report is generated by a bot. It may contain errors.
syzbot ci engineers can be reached at syzkaller@googlegroups.com.
To test a patch for this bug, please reply with `#syz test`
(should be on a separate line).
The patch should be attached to the email.
Note: arguments like custom git repos and branches are not supported.
prev parent reply other threads:[~2026-03-31 7:42 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-30 17:58 [PATCH v2] mm/vmalloc: Use dedicated unbound workqueue for vmap purge/drain Uladzislau Rezki (Sony)
2026-03-30 18:56 ` Andrew Morton
2026-03-31 9:35 ` Uladzislau Rezki
2026-03-30 19:16 ` Andrew Morton
2026-03-31 9:39 ` Uladzislau Rezki
2026-03-31 14:11 ` Uladzislau Rezki
2026-03-31 7:42 ` syzbot ci [this message]
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=69cb7acb.050a0220.183828.0025.GAE@google.com \
--to=syzbot+ci3c65cfe4c9a15aea@syzkaller.appspotmail.com \
--cc=akpm@linux-foundation.org \
--cc=bhe@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lirongqing@baidu.com \
--cc=syzbot@lists.linux.dev \
--cc=syzkaller-bugs@googlegroups.com \
--cc=urezki@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox