[BUG] gfs2: hung task in gfs2_recover_func during journal recovery

Hi,

I am reporting a hung task issue triggered by a syzkaller reproducer on
Linux 7.2-rc3.

The reproducer mounts a crafted GFS2 filesystem image. During mount,
GFS2 enters journal recovery. A kworker from the gfs2_recovery workqueue
gets stuck in I/O wait while running gfs2_recover_func(), and the mounting
syz task is also blocked waiting for journal recovery to complete.

This looks like a potential GFS2 journal recovery hang when processing a
malformed or corrupted filesystem image. The recovery worker waits in
gfs2_jhead_process_page() / gfs2_find_jhead(), while the mount path waits
in gfs2_recover_journal() from gfs2_fill_super().

Reproducer:
syz reproducer: https://pastebin.com/raw/Nt1QNWne
console output: https://pastebin.com/raw/TtBGNqf6
kernel config: https://pastebin.com/raw/ikdiZcSS

Kernel:
kernel version: 7.2.0-rc3 #1 PREEMPT(full)
HEAD commit: 1137d8b5df06137fb49513cc923b3b24d94cb809
environment: QEMU Ubuntu 24.10
taint: Not tainted

Relevant log:

INFO: task kworker/1:4:10801 blocked in I/O wait for more than 142 seconds.
Not tainted 7.2.0-rc3 #1

task/1:4 state stack:24024 pid:10801
Workqueue: gfs2_recovery gfs2_recover_func

Call Trace:
<TASK>
__schedule
schedule
io_schedule
folio_wait_bit_common
gfs2_jhead_process_page
gfs2_find_jhead
gfs2_recover_func
process_scheduled_works
worker_thread
kthread
ret_from_fork
ret_from_fork_asm
</TASK>

Another task is blocked in the mount path:

INFO: task syz.0.18:10824 blocked for more than 142 seconds.
Not tainted 7.2.0-rc3 #1

Call Trace:
<TASK>
__schedule
schedule
bit_wait
__wait_on_bit
out_of_line_wait_on_bit
gfs2_recover_journal
init_inodes
gfs2_fill_super
get_tree_bdev_flags
gfs2_get_tree
vfs_get_tree
fc_mount
path_mount
do_mount
__x64_sys_mount
do_syscall_64
entry_SYSCALL_64_after_hwframe
</TASK>

The system also shows the recovery work item still held by the blocked
worker:

2 locks held by kworker/1:4/10801:
#0: ((wq_completion)gfs2_recovery)
#1: ((work_completion)(&jd->jd_work))

The syzkaller program uses syz_mount_image$gfs2() to mount a crafted GFS2
image. It appears to drive GFS2 into journal recovery, where the recovery
worker waits indefinitely for journal page I/O and prevents the mount path
from making progress.

Thanks