Re: task hung in xlog_grant_head_check - still reproducible on 7.2-rc7 (2018 report went dormant) - and on 5.15.216-stable, with a cascading inodegc victim profile

[Ivan]

Hi,

Picking up Yang Guikun's August report [1] with independent evidence from
our fuzzing fleet -- we agree with the analysis and would like to help get
this unstuck, because the history of this bug now looks like the pre-history
of CVE-2026-109618 (PHP2Shell): a known issue sitting on hard trade-offs
until it becomes an emergency.

INDEPENDENT CONFIRMATION (5.15.216, KASAN, syzkaller):

Our focused XFS campaign reproduces the same hang with a different image
generation and an extra victim profile:

  1. syz_mount_image$xfs -- crafted V4 image (small log)
  2. one setxattr(...) with a large value

  -> xfs_attr_set -> xfs_trans_alloc_inode -> xfs_log_reserve
     -> xlog_grant_head_check -> xlog_grant_head_wait (xfs_log.c:256)

Unlike the August report (V5 image, single victim), our logs show a CASCADE:
the first task wedged is the xfs-inodegc kworker in xfs_inactive_truncate
(D-state >122s), after which user tasks pile up in xfs_trans_alloc behind
the grant wait. All victims are unkillable. So the blast radius is the
whole filesystem, not one unlucky task.

Same root cause as described in [1]: a transaction reservation larger than
the usable log size can never be granted, so xlog_grant_head_wait() is an
unbounded wait -- no amount of log tail pushing can satisfy it.

THE RECORD (why we are pushing now):

- syzbot's main tracker: first report 2018-05-21, open 3079 days,
  1471 crashes, 0 of 29 patches merged, last crash within the last day.
- Sister trackers all open with C repros: linux-4.14 (2450 days),
  linux-4.19 (1412 days), linux-5.15 (1311 days), linux-6.1 (1302 days,
  394 crashes), linux-6.6 (Dec 2025, corrupt-fs images).
- August's report included a concrete, low-risk fix direction (sanity-check
  the reservation against usable log size -> clean -ENOSPC instead of an
  unkillable hang). Neighbor fixes over the years (integer overflow in
  xlog_grant_head_check, the nowait case, ioend log exhaustion) never
closed the unbounded-wait itself.

WHAT WE ARE ASKING FOR:

1. Either accept a reservation-size sanity check (we are happy to test
   patches against our fleet and provide before/after traces), or
2. record an explicit decision (even "won't fix, requires crafted image")
   so that the dormancy becomes a documented choice rather than silence.

We would rather spend our cycles testing your patch than re-reporting this
for the 30th time in 2028.

OFFER:
- Full syzkaller reproducer package (image + prog + C + logs) from both
  campaigns; can also provide a hand-minimized C repro on request.
- Bisect/testing assistance on 5.15-stable and mainline.

[1] https://lists.openwall.net/linux-kernel/2026/08/24/265
    ("task hung in xlog_grant_head_check - still reproducible on 7.2-rc7")

Reported-by: Ivan Vinichuk <ivan.vin.ctf@xxxxxxxxx>