lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHc6FU5eRLt5X7T1BTK2jCuzKc8PHk7wy0UMCVyfBnerSUF7_Q@mail.gmail.com>
Date: Tue, 3 Feb 2026 13:41:22 +0100
From: Andreas Gruenbacher <agruenba@...hat.com>
To: Guilherme Giacomo Simoes <trintaeoitogc@...il.com>
Cc: gfs2@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [RESEND PATCH] gfs2: do not evict glocks with populated address spaces

On Tue, Feb 3, 2026 at 12:43 PM Guilherme Giacomo Simoes
<trintaeoitogc@...il.com> wrote:
> Andreas Gruenbacher <agruenba@...hat.com> 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


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ