Re: iomap_writepages WARN_ON_ONCE(PF_MEMALLOC)

Re: iomap_writepages WARN_ON_ONCE(PF_MEMALLOC)

[Matthew Wilcox]

On Thu, Jul 02, 2026 at 03:59:24AM -0700, Christoph Hellwig wrote:
> On Wed, Jul 01, 2026 at 10:51:06PM +0200, Andreas Gruenbacher wrote:
> > Do you have any suggestions?
> > 
> > The above is on RHEL-8, but a similar code path exists in cgroups v2,
> > triggered via:
> > 
> >   echo reclaim_amount > /sys/fs/cgroup/.../memory.reclaim
> > 
> > That code path starts with:
> > 
> > memory_reclaim -> user_proactive_reclaim -> try_to_free_mem_cgroup_pages ->
> 
> PF_MEMALLOC is a sign of direct reclaim.  cgroup code is doing really
> weird things when it is set and it is doing writeback.

If we're going to blame the cgroup people for doing weird things, let's
cc them so they stand a chance of seeing this ... original at:

https://lore.kernel.org/linux-fsdevel/CAHc6FU4tz8-HmEf2_XKT0NT8N=rv5OMcY79PxTACkXAVLOAUpg@mail.gmail.com/

Re: iomap_writepages WARN_ON_ONCE(PF_MEMALLOC)

[Andreas Gruenbacher]

On Sat, Jul 4, 2026 at 2:57 AM Matthew Wilcox <willy@infradead.org> wrote:
> On Thu, Jul 02, 2026 at 03:59:24AM -0700, Christoph Hellwig wrote:
> > On Wed, Jul 01, 2026 at 10:51:06PM +0200, Andreas Gruenbacher wrote:
> > > Do you have any suggestions?
> > >
> > > The above is on RHEL-8, but a similar code path exists in cgroups v2,
> > > triggered via:
> > >
> > >   echo reclaim_amount > /sys/fs/cgroup/.../memory.reclaim
> > >
> > > That code path starts with:
> > >
> > > memory_reclaim -> user_proactive_reclaim -> try_to_free_mem_cgroup_pages ->
> >
> > PF_MEMALLOC is a sign of direct reclaim.  cgroup code is doing really
> > weird things when it is set and it is doing writeback.
>
> If we're going to blame the cgroup people for doing weird things, let's
> cc them so they stand a chance of seeing this ... original at:
>
> https://lore.kernel.org/linux-fsdevel/CAHc6FU4tz8-HmEf2_XKT0NT8N=rv5OMcY79PxTACkXAVLOAUpg@mail.gmail.com/

This is all pretty ugly: inode_lru_isolate() selects inodes that have
a clear i_state to evict. Among the inodes selected is at least one
gfs2 inode that has the GLF_LFLUSH glock flag is set in
GFS2_I(inode)->i_gl->gl_flags. That flag means that evicting the inode
requires flushing out revokes. Before that log flush can happen,
ordered inodes need to be flushed (ordered journalling mode). And this
is where iomap_writepages() got called.

Unfortunately, filesystems cannot refuse to evict inodes once they are
chosen by inode_lru_isolate().

An acceptable way out may be to set an i_state flag whenever the
GLF_LFLUSH glock flag is set so that inode_lru_isolate() will skip
those problematic inodes.

Thanks,
Andreas