From: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
To: Jiale Yao <yaojiale02@163.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
David Hildenbrand <david@kernel.org>,
"Liam R. Howlett" <liam@infradead.org>,
Vlastimil Babka <vbabka@kernel.org>,
Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm/page_idle: call folio_test_lru() after folio_get()
Date: Wed, 22 Jul 2026 10:56:13 +0100 [thread overview]
Message-ID: <amCSiltZolhgtO3J@lucifer> (raw)
In-Reply-To: <20260722092642.1123347-1-yaojiale02@163.com>
On Wed, Jul 22, 2026 at 05:26:42PM +0800, Jiale Yao wrote:
> page_idle_get_folio() speculatively calls folio_test_lru() before
> folio_try_get(). The folio can get freed and reallocated to a tail page
> in the meantime. In that case, VM_BUG_ON_PGFLAGS() in
> const_folio_flags() can be triggered. Remove the speculative call.
>
> Also mark the folio_test_lru() check right after folio_try_get() success
> as no more unlikely.
Slightly strange wording but not sure why you're doing that? It is
generally unlikely a given folio will be !LRU right?
>
> This is a sibling-path bug: damon_get_folio() was copied from this
> function with the same flawed pattern. Commit d6b8b02a27b3
> ("mm/damon/ops-common: call folio_test_lru() after folio_get()") fixed
> damon_get_folio(), but page_idle_get_folio() was left unfixed. KCSAN
> (strict mode) confirms the data race on the folio flags:
>
> BUG: KCSAN: data-race in ... / percpu_counter_add_batch
> page_idle_get_folio+0x7a/0x2d0
> page_idle_bitmap_read+0xc9/0x220
>
> Signed-off-by: Jiale Yao <yaojiale02@163.com>
Yeah generally this seems obviously correct (TM), if we can't be sure a
folio is kept around any other way to the extent we're doing
folio_try_get() we should gate any actual interactions with the folio on
succeeding the get first...!
With the unlikely thing changed, LGTM so:
Reviewed-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
> ---
> mm/page_idle.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/mm/page_idle.c b/mm/page_idle.c
> index 9c67cbac2965..29ee18f0e8ce 100644
> --- a/mm/page_idle.c
> +++ b/mm/page_idle.c
> @@ -40,9 +40,9 @@ static struct folio *page_idle_get_folio(unsigned long pfn)
> return NULL;
>
> folio = page_folio(page);
> - if (!folio_test_lru(folio) || !folio_try_get(folio))
I guess this was meant as a racey check...
> + if (!folio_try_get(folio))
> return NULL;
> - if (unlikely(page_folio(page) != folio || !folio_test_lru(folio))) {
> + if (unlikely(page_folio(page) != folio) || !folio_test_lru(folio)) {
As above, not sure why you're changing this? Seems unrelated, I'd just keep
it as it was.
> folio_put(folio);
> folio = NULL;
> }
> --
> 2.34.1
>
Cheers, Lorenzo
next prev parent reply other threads:[~2026-07-22 9:56 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-22 9:26 [PATCH] mm/page_idle: call folio_test_lru() after folio_get() Jiale Yao
2026-07-22 9:56 ` Lorenzo Stoakes (ARM) [this message]
2026-07-22 11:20 ` jiale yao
2026-07-22 12:50 ` Lorenzo Stoakes (ARM)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=amCSiltZolhgtO3J@lucifer \
--to=ljs@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=david@kernel.org \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=rppt@kernel.org \
--cc=surenb@google.com \
--cc=vbabka@kernel.org \
--cc=yaojiale02@163.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.