* Re: [PATCH] iomap: allow writeback from kswapd again
2026-11-03 2:38 [PATCH] iomap: allow writeback from kswapd again Yiqing Wu
@ 2026-11-03 4:40 ` Kefeng Wang
2026-11-03 20:07 ` Dave Chinner
1 sibling, 0 replies; 3+ messages in thread
From: Kefeng Wang @ 2026-11-03 4:40 UTC (permalink / raw)
To: Yiqing Wu, Christian Brauner
Cc: gfs2, Andrew Morton, Shakeel Butt, linux-xfs, linux-fsdevel,
linux-kernel, syzbot+5e659793378ad9e06387
On 11/3/2026 10:38 AM, 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
>
> 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. 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.
>
> 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.
>
> Restore the historical semantics of the guard using the
> current_is_kswapd() helper that replaced the PF_KSWAPD flag: warn about
> and refuse writeback from direct or memcg reclaim, but allow it from
> kswapd, as was the case from 2010 until ff59f71f1c95.
I only considered the folio reclaim path and missed that kswapd can
still reach filesystem writeback via the inode shrinkers, thanks for
your fix.
Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com>
>
> Fixes: ff59f71f1c95 ("iomap: simplify writepages reclaim guard")
> Reported-by: syzbot+5e659793378ad9e06387@syzkaller.appspotmail.com
> Closes: https://syzbot.org/bug?extid=5e659793378ad9e06387
> Cc: Christian Brauner <brauner@kernel.org>
> Cc: gfs2@lists.linux.dev
> Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Shakeel Butt <shakeel.butt@linux.dev>
> Cc: linux-xfs@vger.kernel.org
> Cc: linux-fsdevel@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Yiqing Wu <wuyiqing@cmss.chinamobile.com>
> ---
> fs/iomap/buffered-io.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> 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;
>
> while ((folio = writeback_iter(mapping, wpc->wbc, folio, &error))) {
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: [PATCH] iomap: allow writeback from kswapd again
2026-11-03 2:38 [PATCH] iomap: allow writeback from kswapd again Yiqing Wu
2026-11-03 4:40 ` Kefeng Wang
@ 2026-11-03 20:07 ` Dave Chinner
1 sibling, 0 replies; 3+ messages in thread
From: Dave Chinner @ 2026-11-03 20:07 UTC (permalink / raw)
To: Yiqing Wu
Cc: Christian Brauner, gfs2, Kefeng Wang, Andrew Morton, Shakeel Butt,
linux-xfs, linux-fsdevel, linux-kernel,
syzbot+5e659793378ad9e06387
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@suse.cz/
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....
> 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....
> 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@kernel.org
^ permalink raw reply [flat|nested] 3+ messages in thread