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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aOPAay5im1lJhHFm@shell.ilvokhin.com>
Date: Mon, 6 Oct 2025 13:13:15 +0000
From: Dmitry Ilvokhin <d@...okhin.com>
To: Kiryl Shutsemau <kas@...nel.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
	Kemeng Shi <shikemeng@...weicloud.com>,
	Kairui Song <kasong@...cent.com>, Nhat Pham <nphamcs@...il.com>,
	Baoquan He <bhe@...hat.com>, Barry Song <baohua@...nel.org>,
	Chris Li <chrisl@...nel.org>,
	Axel Rasmussen <axelrasmussen@...gle.com>,
	Yuanchu Xie <yuanchu@...gle.com>, Wei Xu <weixugc@...gle.com>,
	Usama Arif <usamaarif642@...il.com>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, kernel-team@...a.com
Subject: Re: [PATCH] mm: skip folio_activate() for mlocked folios

On Mon, Oct 06, 2025 at 12:07:48PM +0000, Dmitry Ilvokhin wrote:
> On Fri, Oct 03, 2025 at 03:41:05PM +0100, Kiryl Shutsemau wrote:
> > On Fri, Oct 03, 2025 at 02:19:55PM +0000, Dmitry Ilvokhin wrote:
> > > __mlock_folio() should update stats, when lruvec_add_folio() is called,
> > 
> > The update of stats is incidental to moving to unevicable LRU. But okay.
> > 
> 
> Good point. I'll rephrase commit message in terms of unevicable
> LRU instead of stat updates in v2.
> 
> > > but if folio_test_clear_lru() check failed, then __mlock_folio() gives
> > > up early. From the other hand, folio_mark_accessed() calls
> > > folio_activate() which also calls folio_test_clear_lru() down the line.
> > > When folio_activate() successfully removed folio from LRU,
> > > __mlock_folio() will not update any stats, which will lead to inaccurate
> > > values in /proc/meminfo as well as cgroup memory.stat.
> > > 
> > > To prevent this case from happening also check for folio_test_mlocked()
> > > in folio_mark_accessed(). If folio is not yet marked as unevictable, but
> > > already marked as mlocked, then skip folio_activate() call to allow
> > > __mlock_folio() to make all necessary updates.
> > > 
> > > To observe the problem mmap() and mlock() big file and check Unevictable
> > > and Mlocked values from /proc/meminfo. On freshly booted system without
> > > any other mlocked memory we expect them to match or be quite close.
> > > 
> > > See below for more detailed reproduction steps. Source code of stat.c
> > > is available at [1].
> > > 
> > >   $ head -c 8G < /dev/urandom > /tmp/random.bin
> > > 
> > >   $ cc -pedantic -Wall -std=c99 stat.c -O3 -o /tmp/stat
> > >   $ /tmp/stat
> > >   Unevictable:     8389668 kB
> > >   Mlocked:         8389700 kB
> > > 
> > >   Need to run binary twice. Problem does not reproduce on the first run,
> > >   but always reproduces on the second run.
> > > 
> > >   $ /tmp/stat
> > >   Unevictable:     5374676 kB
> > >   Mlocked:         8389332 kB
> > 
> > I think it is worth starting with the problem statement.
> > 
> > I like to follow this pattern of commit messages:
> > 
> > <Background, if needed>
> > 
> > <Issue statement>
> > 
> > <Proposed solution>
> >
> 
> Thanks for suggestion, v2 commit message will much this pattern.
> 
> > > 
> > > [1]: https://gist.github.com/ilvokhin/e50c3d2ff5d9f70dcbb378c6695386dd
> > > 
> > > Co-developed-by: Kiryl Shutsemau <kas@...nel.org>
> > > Signed-off-by: Kiryl Shutsemau <kas@...nel.org>
> > > Signed-off-by: Dmitry Ilvokhin <d@...okhin.com>
> > 
> > Your Co-developed-by is missing. See submitting-patches.rst.
> > 
> 
> I followed an example of a patch submitted by the From: author from
> submitting-patches.rst. This example doesn't have Co-developed-by tag
> from the From Author. That's being said, I found both cases usage in the
> mm commit log, so I'll add mine Co-developed-by tag in the v2.

Turns out scripts/checkpatch.pl is able to catch that with the following
message: "Co-developed-by: should not be used to attribute nominal patch
author", so I'll obey automation suggestion here and will not add mine
Co-developed-by tag here.

> 
> > > ---
> > >  mm/swap.c | 10 ++++++++++
> > >  1 file changed, 10 insertions(+)
> > > 
> > > diff --git a/mm/swap.c b/mm/swap.c
> > > index 2260dcd2775e..f682f070160b 100644
> > > --- a/mm/swap.c
> > > +++ b/mm/swap.c
> > > @@ -469,6 +469,16 @@ void folio_mark_accessed(struct folio *folio)
> > >  		 * this list is never rotated or maintained, so marking an
> > >  		 * unevictable page accessed has no effect.
> > >  		 */
> > > +	} else if (folio_test_mlocked(folio)) {
> > > +		/*
> > > +		 * Pages that are mlocked, but not yet on unevictable LRU.
> > > +		 * They might be still in mlock_fbatch waiting to be processed
> > > +		 * and activating it here might interfere with
> > > +		 * mlock_folio_batch(). __mlock_folio() will fail
> > > +		 * folio_test_clear_lru() check and give up. It happens because
> > > +		 * __folio_batch_add_and_move() clears LRU flag, when adding
> > > +		 * folio to activate batch.
> > > +		 */
> > >  	} else if (!folio_test_active(folio)) {
> > >  		/*
> > >  		 * If the folio is on the LRU, queue it for activation via
> > > -- 
> > > 2.47.3
> > > 
> > 
> > -- 
> >   Kiryl Shutsemau / Kirill A. Shutemov

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ