Re: [PATCH] iomap: allow writeback from kswapd again

[Andreas Gruenbacher]

On Tue, Nov 3, 2026 at 9:17 PM Dave Chinner <dgc@xxxxxxxxxx> wrote:
> On Tue, Nov 03, 2026 at 10:38:04AM +0800, Yiqing Wu wrote:
> > Commit ff59f71f1c95 ("iomap: simplify writepages reclaim guard") removed
> > the PF_KSWAPD exemption from the iomap_writepages() guard on the
> > assumption that kswapd can no longer reach filesystem writeback now
> > that pageout() returns PAGE_ACTIVATE for non-shmem, non-anon folios.
> > That assumption only covers the folio reclaim path.  kswapd can still
> > reach filesystem writeback through the inode shrinkers, and syzbot
> > reports exactly that on GFS2:
> >
> >   WARNING: (current->flags & PF_MEMALLOC) in iomap_writepages
> >   kswapd -> balance_pgdat -> shrink_node -> shrink_slab
> >   -> super_cache_scan -> prune_icache_sb -> evict
> >   -> gfs2_evict_inode -> evict_linked_inode -> gfs2_log_flush
> >   -> gfs2_ordered_write -> filemap_fdatawrite -> do_writepages
> >   -> gfs2_writepages -> iomap_writepages
>
> Oh, that's awful. Nothing should be calling into iomap_writepages
> from reclaim context.
>
> i.e. Doing data writeback from the inode cache shrinker is extremely
> suboptimal for many reasons, so I'd consider this a gfs2 bug, not an
> iomap issue. It's even worse when data writeback is being driven by
> an inode cache shrinker. I'm surprised that lockdep hasn't thrown a
> hissy-fit over this (i.e. inode locks taken in writeback appearing
> both above and below reclaim.
>
> This is the patch series that Jan Kara came up with to deal with
> these issues in inode eviction:
>
> https://lore.kernel.org/linux-fsdevel/20261009133253.20102-1-jack@xxxxxxx/
>
> This allows filesystems to defer inode eviction that might block
> (e.g. due to transaction reservations, journal commits, metadata
> read requirements, data writeback requirements, etc) to a context
> where the work is allowed to block and isn't running under memory
> reclaim context or restrictions.
>
> That patchset is needed for ext4, XFS alreayd does this, and it
> would seem that gfs2 needs it for glock reclaim....

Yes, Jan's deferred inode reclaim patch queue (plus a tiny gfs2 patch
on top) should take care of that.

I see that Jan wanted to send a v4 of this patch queue. Are there any
remaining serious problems?

> > Under memory pressure kswapd evicts GFS2 inodes whose glock is still
> > dirty, and gfs2_evict_inode() -> gfs2_log_flush() ->
> > gfs2_ordered_write() then writes back the ordered data of every inode
> > on sd_log_ordered.  This is long-standing, intentional behaviour: in
> > the default data=ordered mode GFS2 must flush dirty data before the
> > log commit that writes the metadata.
>
> It's also long standing, known broken behaviour w.r.t. shrinkers
> running in memory reclaim contexts.
>
> So, why doesn't this warning happen through the direct reclaim path?
> i.e.  what makes only kswapd trigger this?
>
> I see nothing that prevents direct reclaim doing inode eviction
> from triggering this same path through gfs2_evict_inode(). IOWs,
> direct reclaim should also be triggering the warning in
> iomap_writepages(), hence it is not clear to me why re-adding the
> kswapd guard is anything other than a band-aid over the broken code
> in gfs2....

It's also happening under direct reclaim. Here is an attempt at a fix
from before I was aware of Jan's patch queue that describes such a
scenario:

https://lore.kernel.org/gfs2/20260921211712.1563575-1-agruenba@xxxxxxxxxx/

> > Writeback from kswapd has been
> > explicitly allowed since 2010, when the guard was still in XFS:
> > commit d4f7a5cbd544 ("xfs: allow writeback from kswapd"), because
> > the kswapd stack usage is low and it cannot deadlock on the
> > filesystem.
>
> No, that was a regression fix for turning off all writeback from
> reclaim in XFS as a 'what problems does stopping mm reclaim
> writeback actually cause' experiment. That was the first steps we
> took down the path to get rid of the problematic random dirty page
> writeback issues that memory reclaim had.
>
> IOWs, we didn't want to allow it, but we had to tolerate it because
> the MM behaviour was unfixable at the time. Now that the
> pageout()->.writepage() path for dirty filebacked page writeback is
> gone from the mm, we no longer have to tolerate this behaviour
> and so the guard got removed. It only took 15 years to get to this
> point....
>
> tl;dr: Writeback through iomap in memory reclaim context is -a bug-.
>
> > Beyond the noisy warning the new guard is actively harmful: it returns
> > -EIO on every hit (WARN_ON_ONCE only limits the report), while
> > gfs2_ordered_write() ignores the filemap_fdatawrite() return value, so
> > the log commit proceeds with metadata even though the ordered data was
> > never written, breaking the data-before-metadata ordering guarantee of
> > data=ordered mode.
>
> This is definitely a gfs2 bug - writeback can fail for -many-
> reasons, so ignoring IO submission failures when data integrity is
> required is a definitely filesystem bug.
>
> > diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
> > index d6e2f1ded5ca..324da0f5cb29 100644
> > --- a/fs/iomap/buffered-io.c
> > +++ b/fs/iomap/buffered-io.c
> > @@ -2082,7 +2082,7 @@ iomap_writepages(struct iomap_writepage_ctx *wpc)
> >        * Writeback from reclaim context should never happen except in the case
> >        * of a VM regression so warn about it and refuse to write the data.
> >        */
> > -     if (WARN_ON_ONCE((current->flags & PF_MEMALLOC)))
> > +     if (WARN_ON_ONCE((current->flags & PF_MEMALLOC) && !current_is_kswapd()))
> >               return -EIO;
>
> AFAICT, direct reclaim will still trigger this warning and the bad
> gfs2 behaviour, so I'm struggling to see this as anything other than
> shooting the messenger...
>
> Cheers,
>
> Dave.
> --
> Dave Chinner
> dgc@xxxxxxxxxx

Thanks,
Andreas