Re: [RESEND PATCH] gfs2: do not evict glocks with populated address spaces

On Tue, Feb 3, 2026 at 12:43 PM Guilherme Giacomo Simoes
<[email protected]> wrote:
> Andreas Gruenbacher <[email protected]> wrote:
> > > Metadata glocks may have associated address spaces used as caches. Avoid
> > > reclaiming such glocks under memory pressure while their mappings are
> > > still populated or their state is not unlocked, as this can lead to
> > > invalid page cache state and GLOCK_BUG_ON().
> >
> > What invalid page cache state and GLOCK_BUG_ON() errors is this about, exactly?
>
> On __gfs2_glock_put() (fs/gfs2/glock.c) the GLOCK_BUG_ON() is triggered under
> memory pressure while the glock is still locked or the glock is populated with
> metadata caches.

There are two GLOCK_BUG_ON() assertions in __gfs2_glock_put(). I
assume you are talking about this one:

GLOCK_BUG_ON(gl, !list_empty(&gl->gl_holders));

This should never trigger because each holder has a glock reference
(see the gfs2_glock_hold() in __gfs2_holder_init()), and so
gl->gl_lockref should never reach zero while there are holders.

If none of the holders has the HIF_HOLDER flag set, we don't know if
the glock is actually locked.

> This happens because the __gfs2_glock_put() can't truncate pages with a private
> datas (truncate_inode_pages_final(mapping) is failed), how the metadata is a
> private folio, the GLOCK_BUG_ON(gl, !mapping_empty(mapping)) is trigged.

What are the actual messages you are getting?

> > This leaks a glock reference, so it's definitely wrong.
>
> But this glock is a private folio with metadata or is still locked. I think
> this can't be evictable

What even makes you think these glocks are evictable?

Thanks,
Andreas