possible deadlock in jffs2_do_clear_inode

Status: upstream: reported on 2026/09/06 08:21
Reported-by: syzbot+b4e79cf8509f1f466c7f@syzkaller.appspotmail.com
First crash: 10d, last: 10d
Similar bugs (3)
Kernel Title Rank 🛈 Repro Cause bisect Fix bisect Count Last Reported Patched Status
upstream possible deadlock in jffs2_do_clear_inode (2) prio:low jffs2 4 syz, C 2130 21m 40d 0/29 upstream: reported C repro on 2026/08/07 00:00
upstream possible deadlock in jffs2_do_clear_inode jffs2 4 3 885d 889d 0/29 auto-obsoleted due to no activity on 2024/07/22 21:36
linux-6.1 possible deadlock in jffs2_do_clear_inode 4 2 29d 42d 0/3 upstream: reported on 2026/08/05 01:02

Sample crash report:
======================================================
WARNING: possible circular locking dependency detected
syzkaller #0 Not tainted
------------------------------------------------------
kswapd0/254 is trying to acquire lock:
ffff88805e95af28 (&f->sem){+.+.}-{3:3}, at: jffs2_do_clear_inode+0x5e/0x390 fs/jffs2/readinode.c:1419

but task is already holding lock:
ffffffff8c3decc0
 (fs_reclaim){+.+.}-{0:0}, at: 0x1

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-> #1 (fs_reclaim){+.+.}-{0:0}:
       __fs_reclaim_acquire mm/page_alloc.c:4580 [inline]
       fs_reclaim_acquire+0x6d/0x100 mm/page_alloc.c:4594
       might_alloc include/linux/sched/mm.h:206 [inline]
       slab_pre_alloc_hook+0x20/0xc0 mm/slab.h:492
       slab_alloc_node mm/slub.c:3139 [inline]
       slab_alloc mm/slub.c:3233 [inline]
       kmem_cache_alloc+0x3d/0x280 mm/slub.c:3238
       jffs2_do_read_inode+0x2ff/0x640 fs/jffs2/readinode.c:1372
       jffs2_iget+0x20f/0xc60 fs/jffs2/fs.c:277
       jffs2_do_fill_super+0x599/0xc50 fs/jffs2/fs.c:577
       mtd_get_sb+0xcb/0x2b0 drivers/mtd/mtdsuper.c:79
       get_tree_mtd+0x5e2/0x760 drivers/mtd/mtdsuper.c:163
       vfs_get_tree+0x88/0x270 fs/super.c:1541
       do_new_mount+0x247/0xa40 fs/namespace.c:3034
       do_mount fs/namespace.c:3377 [inline]
       __do_sys_mount fs/namespace.c:3585 [inline]
       __se_sys_mount+0x2e3/0x3d0 fs/namespace.c:3562
       do_syscall_x64 arch/x86/entry/common.c:50 [inline]
       do_syscall_64+0x4c/0xa0 arch/x86/entry/common.c:80
       entry_SYSCALL_64_after_hwframe+0x66/0xd0

-> #0 (&f->sem){+.+.}-{3:3}:
       check_prev_add kernel/locking/lockdep.c:3053 [inline]
       check_prevs_add kernel/locking/lockdep.c:3172 [inline]
       validate_chain kernel/locking/lockdep.c:3788 [inline]
       __lock_acquire+0x2c66/0x7b50 kernel/locking/lockdep.c:5012
       lock_acquire+0x19e/0x400 kernel/locking/lockdep.c:5623
       __mutex_lock_common+0x1e5/0x2400 kernel/locking/mutex.c:596
       __mutex_lock kernel/locking/mutex.c:729 [inline]
       mutex_lock_nested+0x17/0x20 kernel/locking/mutex.c:743
       jffs2_do_clear_inode+0x5e/0x390 fs/jffs2/readinode.c:1419
       evict+0x4b6/0x8b0 fs/inode.c:647
       dispose_list fs/inode.c:680 [inline]
       prune_icache_sb+0x220/0x2d0 fs/inode.c:879
       super_cache_scan+0x335/0x430 fs/super.c:107
       do_shrink_slab+0x51f/0xd40 mm/vmscan.c:765
       shrink_slab_memcg mm/vmscan.c:834 [inline]
       shrink_slab+0x43d/0x7a0 mm/vmscan.c:913
       shrink_node_memcgs mm/vmscan.c:2958 [inline]
       shrink_node+0x11f5/0x2790 mm/vmscan.c:3079
       kswapd_shrink_node mm/vmscan.c:3821 [inline]
       balance_pgdat+0xdf3/0x1a10 mm/vmscan.c:4012
       kswapd+0x7db/0xde0 mm/vmscan.c:4271
       kthread+0x42e/0x520 kernel/kthread.c:334
       ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:287

other info that might help us debug this:

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(fs_reclaim);
                               lock(&f->sem);
                               lock(fs_reclaim);
  lock(&f->sem);

 *** DEADLOCK ***

3 locks held by kswapd0/254:
 #0: ffffffff8c3decc0 (fs_reclaim){+.+.}-{0:0}, at: 0x1
 #1: ffffffff8c3bc2d0 (shrinker_rwsem){++++}-{3:3}, at: shrink_slab_memcg mm/vmscan.c:807 [inline]
 #1: ffffffff8c3bc2d0 (shrinker_rwsem){++++}-{3:3}, at: shrink_slab+0x228/0x7a0 mm/vmscan.c:913
 #2: ffff888067f2e0e0 (&type->s_umount_key#83){++++}-{3:3}, at: trylock_super fs/super.c:418 [inline]
 #2: ffff888067f2e0e0 (&type->s_umount_key#83){++++}-{3:3}, at: super_cache_scan+0x70/0x430 fs/super.c:80

stack backtrace:
CPU: 0 PID: 254 Comm: kswapd0 Not tainted syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/24/2026
Call Trace:
 <TASK>
 dump_stack_lvl+0x188/0x250 lib/dump_stack.c:106
 check_noncircular+0x296/0x330 kernel/locking/lockdep.c:2133
 check_prev_add kernel/locking/lockdep.c:3053 [inline]
 check_prevs_add kernel/locking/lockdep.c:3172 [inline]
 validate_chain kernel/locking/lockdep.c:3788 [inline]
 __lock_acquire+0x2c66/0x7b50 kernel/locking/lockdep.c:5012
 lock_acquire+0x19e/0x400 kernel/locking/lockdep.c:5623
 __mutex_lock_common+0x1e5/0x2400 kernel/locking/mutex.c:596
 __mutex_lock kernel/locking/mutex.c:729 [inline]
 mutex_lock_nested+0x17/0x20 kernel/locking/mutex.c:743
 jffs2_do_clear_inode+0x5e/0x390 fs/jffs2/readinode.c:1419
 evict+0x4b6/0x8b0 fs/inode.c:647
 dispose_list fs/inode.c:680 [inline]
 prune_icache_sb+0x220/0x2d0 fs/inode.c:879
 super_cache_scan+0x335/0x430 fs/super.c:107
 do_shrink_slab+0x51f/0xd40 mm/vmscan.c:765
 shrink_slab_memcg mm/vmscan.c:834 [inline]
 shrink_slab+0x43d/0x7a0 mm/vmscan.c:913
 shrink_node_memcgs mm/vmscan.c:2958 [inline]
 shrink_node+0x11f5/0x2790 mm/vmscan.c:3079
 kswapd_shrink_node mm/vmscan.c:3821 [inline]
 balance_pgdat+0xdf3/0x1a10 mm/vmscan.c:4012
 kswapd+0x7db/0xde0 mm/vmscan.c:4271
 kthread+0x42e/0x520 kernel/kthread.c:334
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:287
 </TASK>

Crashes (1):
Time Kernel Commit Syzkaller Config Log Report Syz repro C repro VM info Assets (help?) Manager Title
2026/09/06 08:20 linux-5.15.y 0996e0926f6b 4f7b22a0 .config console log report info [disk image] [vmlinux] [kernel image] ci2-linux-5-15-kasan possible deadlock in jffs2_do_clear_inode
* Struck through repros no longer work on HEAD.