Re: inconsistent lock state in the new fserror code

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

On Mon, Feb 16, 2026 at 09:47:45PM -0800, Christoph Hellwig wrote:
> On Sat, Feb 14, 2026 at 09:38:26AM +1100, Dave Chinner wrote:
> > Yeah, that seems like a bug that needs fixing in the
> > ioend_writeback_end_bio() function - if there's an IO error, it
> > needs to punt the processing of the ioend to a workqueue...
> 
> The iomap code doesn't have a workqueue currently.  The way we split
> the code, we left the workqueue handling in XFS, because it is anchored
> in the inode.  I've been wanting to have it generic, as it would help
> with various other things, though.
> 
> For XFS we might be able to just always hook into our I/O completion
> handler and shortcut the workqueue for pure overwrites without errors,
> but that won't help other users like the block device code, zonefs and
> gfs2.  Maybe we'll need an opt-in for the fserror reporting now to
> exclude them?

<shrug> Assuming that file IO errors aren't a frequent occurrence, it's
easy enough to attach them to a global list and schedule_worker to
process the list when an error comes in.

> On something related, if we require a user context for fserror_report
> anyway, there is no need for the workqueue bouncing in it.

Bouncing the fserror_event to an async kworker is useful for laundering
the inode locking context -- fsnotify and ->report_error know they're
running in process context without any filesystem locks held.

I tried getting rid of the wq bouncing and immediately ran into the same
lockdep complaint but on xfs_inode::i_flags_lock.

--D