Re: [Bug][xfstests xfs/556] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage

["Darrick J. Wong" <djwong@kernel.org>]

On Fri, Mar 20, 2026 at 12:23:55AM -0700, Christoph Hellwig wrote:
> On Fri, Mar 20, 2026 at 03:43:03AM +0800, Zorro Lang wrote:
> > Hi,
> > 
> > While running fstests xfs/556 on kernel 7.0.0-rc4+ (HEAD=04a9f1766954), a
> > lockdep warning was triggered indicating an inconsistent lock state for
> > sb->s_type->i_lock_key.
> > 
> > The deadlock might occur because iomap_read_end_io (called from a hardware
> > interrupt completion path) invokes fserror_report, which then calls igrab.
> > igrab attempts to acquire the i_lock spinlock. However, the i_lock is frequently
> > acquired in process context with interrupts enabled. If an interrupt occurs while
> > a process holds the i_lock, and that interrupt handler calls fserror_report, the
> > system deadlocks.
> > 
> > I hit this warning several times by running xfs/556 (mostly) or generic/648
> > on xfs. More details refer to below console log.
> 
> I've seen the same.  AFAIK this is because the patch Darrick did to
> offload all bio errors to a workque hasn't been merged upstream.
> Unfortunately I don't remember the subject for that anymore.

That was only for writeback ioends[1], which went upstream a couple of
weeks ago.  This report is for read(ahead) completions, but there isn't
a quick fix because (AFAIK) the readahead ctx is gone by the time we get
to the bio endio handler.  I think we'd have to allocate a new struct
{bio, list_head} in iomap_read_end_io and bump the
iomap_finish_folio_read calls to process context via queue_work().

--D

[1] https://lore.kernel.org/linux-fsdevel/177148129564.716249.3069780698231701540.stgit@frogsfrogsfrogs/