[Linux Kernel Bug] INFO: task hung in gfs2_logd
From: Jiaming Zhang
Date: Wed Jul 08 2026 - 08:30:59 EST
Dear Linux kernel developers and maintainers,
We are writing to report a task hung issue discovered in the GFS2
subsystem. The issue is reproducible on the latest version of linux
(v7.2-rc2, commit 8cdeaa50eae8dad34885515f62559ee83e7e8dda). Below is
the kernel report:
---
INFO: task gfs2_logd/syz:s:9474 blocked for more than 143 seconds.
Not tainted 7.2.0-rc2-00001-g946f2468cbdc #3
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:gfs2_logd/syz:s state:D stack:29288 pid:9474 tgid:9474 ppid:2
task_flags:0x200040 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5510 [inline]
__schedule+0x1743/0x55b0 kernel/sched/core.c:7234
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0x165/0x2b0 kernel/sched/core.c:7326
schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:7383
rwsem_down_write_slowpath+0x874/0x1010 kernel/locking/rwsem.c:1215
__down_write_common kernel/locking/rwsem.c:1347 [inline]
__down_write kernel/locking/rwsem.c:1356 [inline]
down_write+0x1ab/0x1f0 kernel/locking/rwsem.c:1632
gfs2_logd+0x27a/0x10b0 fs/gfs2/log.c:1351
kthread+0x389/0x480 kernel/kthread.c:436
ret_from_fork+0x509/0xb70 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
</TASK>
Showing all locks held in the system:
5 locks held by kworker/u10:1/32:
1 lock held by khungtaskd/35:
#0: ffffffff8e55a1c0 (rcu_read_lock){....}-{1:3}, at:
rcu_lock_acquire include/linux/rcupdate.h:300 [inline]
#0: ffffffff8e55a1c0 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock
include/linux/rcupdate.h:840 [inline]
#0: ffffffff8e55a1c0 (rcu_read_lock){....}-{1:3}, at:
debug_show_all_locks+0x2e/0x180 kernel/locking/lockdep.c:6775
3 locks held by syz-executor108/9460:
1 lock held by gfs2_logd/syz:s/9474:
#0: ffff8880278dce80 (&sdp->sd_log_flush_lock){++++}-{4:4}, at:
gfs2_logd+0x27a/0x10b0 fs/gfs2/log.c:1351
2 locks held by gfs2_quotad/syz/9475:
#0: ffff888023d04640 (sb_internal#2){.+.+}-{0:0}, at:
gfs2_trans_begin+0x6f/0xe0 fs/gfs2/trans.c:123
#1: ffff8880278dce80 (&sdp->sd_log_flush_lock){++++}-{4:4}, at:
__gfs2_trans_begin+0x519/0x900 fs/gfs2/trans.c:87
=============================================
NMI backtrace for cpu 0
CPU: 0 UID: 0 PID: 35 Comm: khungtaskd Not tainted
7.2.0-rc2-00001-g946f2468cbdc #3 PREEMPT(full)
Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix,
1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x10e/0x190 lib/dump_stack.c:120
nmi_cpu_backtrace+0x274/0x2d0 lib/nmi_backtrace.c:122
nmi_trigger_cpumask_backtrace+0x17a/0x380 lib/nmi_backtrace.c:65
trigger_all_cpu_backtrace include/linux/nmi.h:162 [inline]
__sys_info lib/sys_info.c:157 [inline]
sys_info+0x135/0x170 lib/sys_info.c:165
check_hung_uninterruptible_tasks kernel/hung_task.c:353 [inline]
watchdog+0xfdf/0x1040 kernel/hung_task.c:561
kthread+0x389/0x480 kernel/kthread.c:436
ret_from_fork+0x509/0xb70 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
</TASK>
Sending NMI from CPU 0 to CPUs 1:
NMI backtrace for cpu 1
CPU: 1 UID: 0 PID: 9460 Comm: syz-executor108 Not tainted
7.2.0-rc2-00001-g946f2468cbdc #3 PREEMPT(full)
Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix,
1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
RIP: 0010:do_raw_spin_lock+0xa/0x260 kernel/locking/spinlock_debug.c:114
Code: c1 7c 90 48 89 df e8 f5 02 91 00 eb 86 0f 1f 00 90 90 90 90 90
90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 55 48 89 e5 41 57 <41> 56
41 55 41 54 53 48 83 e4 e0 48 81 ec 80 00 00 00 48 89 fb 65
RSP: 0018:ffffc90003777748 EFLAGS: 00000296
RAX: abc1b017099cbe00 RBX: ffff888044d2c7b8 RCX: 0000000080000001
RDX: 0000000000000000 RSI: ffffffff8dd65db5 RDI: ffff8880278dcf18
RBP: ffffc90003777750 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: ffffffff841989b2 R12: 1ffff110089a58f7
R13: ffff888045c47218 R14: 0000000000000000 R15: ffff8880278dcf60
FS: 000055555e67e380(0000) GS:ffff8880ebe25000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000556a433c4638 CR3: 0000000043a37000 CR4: 0000000000752ef0
PKRU: 55555554
Call Trace:
<TASK>
spin_lock include/linux/spinlock.h:342 [inline]
gfs2_ail1_start_one fs/gfs2/log.c:143 [inline]
gfs2_ail1_flush+0xce2/0xfb0 fs/gfs2/log.c:218
gfs2_ail1_start fs/gfs2/log.c:249 [inline]
empty_ail1_list+0x13d/0x260 fs/gfs2/log.c:978
__gfs2_log_flush+0x176a/0x1d70 fs/gfs2/log.c:1167
gfs2_log_flush+0x34/0x50 fs/gfs2/log.c:1216
gfs2_kill_sb+0x5c/0x430 fs/gfs2/ops_fstype.c:1779
deactivate_locked_super+0xbc/0x130 fs/super.c:477
cleanup_mnt+0x425/0x4c0 fs/namespace.c:1317
task_work_run+0x1d4/0x260 kernel/task_work.c:233
resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]
__exit_to_user_mode_loop kernel/entry/common.c:70 [inline]
exit_to_user_mode_loop+0x207/0x7c0 kernel/entry/common.c:101
__exit_to_user_mode_prepare include/linux/irq-entry-common.h:207 [inline]
syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:230 [inline]
syscall_exit_to_user_mode include/linux/entry-common.h:318 [inline]
do_syscall_64+0x353/0x5c0 arch/x86/entry/syscall_64.c:100
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f608523e48b
Code: ea 75 a4 c7 05 4e 85 0a 00 00 00 00 00 eb 98 e8 bb 07 00 00 66
2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 a6 00 00 00 0f 05 <48> 3d
00 f0 ff ff 77 05 c3 0f 1f 40 00 48 c7 c2 c0 ff ff ff f7 d8
RSP: 002b:00007ffeb55b0b78 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00007f608523e48b
RDX: 00007f6085220ea8 RSI: 0000000000000009 RDI: 00007ffeb55b0c40
RBP: 00007ffeb55b0c40 R08: 0000000000000073 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffeb55b1ce0
R13: 000055555e67f6e0 R14: 0000000000000001 R15: 431bde82d7b634db
</TASK>
---
Following is the root cause analysis for this issue, note that
analysis is performed with the assistance of LLM, it maybe inaccurate.
The root cause for this issue is that, during unmount, gfs2_kill_sb()
performs a synchronous log flush before the GFS2 background log and
quota threads are stopped. Given a corrupted GFS2 image, the
synchronous flush can spend a long time in empty_ail1_list() /
gfs2_ail1_flush() while holding sdp->sd_log_flush_lock.
While the unmount path is holding sd_log_flush_lock, gfs2_logd can
wake up and try to acquire the same lock for write in gfs2_logd(). At
the same time, gfs2_quotad can try to start a transaction through
gfs2_statfs_sync() and block on sd_log_flush_lock for read in
__gfs2_trans_begin(). Both background threads can remain in D state
long enough to trigger the hung task issue.
To fix this issue, we can stop the GFS2 background threads by calling
gfs2_destroy_threads(sdp) before gfs2_kill_sb() starts the synchronous
log flush. gfs2_destroy_threads() calls kthread_stop_put() for
sd_logd_process and sd_quotad_process, so it waits until gfs2_logd and
gfs2_quotad have actually exited. After that, the following
gfs2_log_flush() may still take time to drain the AIL, but no live
background log or quota thread can enter gfs2_logd() or
gfs2_statfs_sync() and block behind sd_log_flush_lock. This avoids the
reported D-state wait in gfs2_logd/gfs2_quotad without changing the
log flush itself.
```
diff --git a/fs/gfs2/ops_fstype.c b/fs/gfs2/ops_fstype.c
index 9b9e70f14d25..d087845a75d6 100644
--- a/fs/gfs2/ops_fstype.c
+++ b/fs/gfs2/ops_fstype.c
@@ -1776,6 +1776,8 @@ static void gfs2_kill_sb(struct super_block *sb)
return;
}
+ gfs2_destroy_threads(sdp);
+
gfs2_log_flush(sdp, NULL, GFS2_LOG_HEAD_FLUSH_SYNC | GFS2_LFC_KILL_SB);
dput(sdp->sd_root_dir);
dput(sdp->sd_master_dir);
```
After applying the above patch, the reproducer no longer triggers the
issue on my machine.
If this solution is acceptable, we are happy to submit a formal patch.
The kernel console output, kernel config, syzkaller reproducer, and C
reproducer are available at google drive:
https://drive.google.com/drive/folders/1_RQO1w7qM5RU5ibdiq09Mpr96E6IITH0?usp=sharing
Please let me know if any further information is required.
Best Regards,
Jiaming Zhang