linux-kernel - Re: [PATCH v2] mm: skip folio_activate() for mlocked folios

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] [day] [month] [year] [list]

Message-Id: <20251007195313.7336-1-sj@kernel.org>
Date: Tue,  7 Oct 2025 12:53:13 -0700
From: SeongJae Park <sj@...nel.org>
To: Dmitry Ilvokhin <d@...okhin.com>
Cc: SeongJae Park <sj@...nel.org>,
	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>,
	Kiryl Shutsemau <kas@...nel.org>,
	Usama Arif <usamaarif642@...il.com>,
	linux-mm@...ck.org,
	linux-kernel@...r.kernel.org,
	kernel-team@...a.com
Subject: Re: [PATCH v2] mm: skip folio_activate() for mlocked folios

On Mon, 6 Oct 2025 13:25:26 +0000 Dmitry Ilvokhin <d@...okhin.com> wrote:

> __mlock_folio() does not move folio to unevicable LRU, when
> folio_activate() removes folio from LRU.

A trivial opinion.  So the user-visible issue is the incorrect meminfo, right?

I read your changelog below saying you changed this message from v1 to frame on
unevictable LRU rather than stat accounting, and I think that's nice to
understand the detail.  But I think further describing the resulting
user-visible issue can be helpful at better understanding the motivation of
this nice patch.

> 
> To prevent this case 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. It should be safe to skip
> folio_activate() here, because mlocked folio should end up in
> unevictable LRU eventually anyway.
> 
> 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
> 
> [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>
> Acked-by: Usama Arif <usamaarif642@...il.com>

Because this is a fix of a user-visible issue, I'm wondering if this deserves
Fixes: and Cc: stable@.

Anyway my comments are only trivial ones, and I think the change is good.

Reviewed-by: SeongJae Park <sj@...nel.org>

> ---
> Changes in v2:
>   - Rephrase commit message: frame it in terms of unevicable LRU, not stat
>     accounting.

Yet another trivial and personal opinion.  Adding a link to the previous
version could be helpful for reviewers like me.

Thanks,
SJ

[...]