From: "Zi Yan" <ziy@nvidia.com>
To: "Matthew Wilcox" <willy@infradead.org>,
"Yafang Shao" <laoar.shao@gmail.com>
Cc: <akpm@linux-foundation.org>, <david@kernel.org>,
<matthew.brost@intel.com>, <joshua.hahnjy@gmail.com>,
<byungchul@sk.com>, <gourry@gourry.net>,
<ying.huang@linux.alibaba.com>, <apopple@nvidia.com>,
<linux-mm@kvack.org>, "Huang, Ying" <ying.huang@intel.com>
Subject: Re: [PATCH] mm/migrate: snapshot the source nid before the misplaced migration
Date: Fri, 23 Oct 2026 10:11:34 -0400 [thread overview]
Message-ID: <DMCA1N4UNM7G.3JBXJHJE6CQ7V@nvidia.com> (raw)
In-Reply-To: <atrUeGPZgoSACpOR@casper.infradead.org>
On Thu Oct 22, 2026 at 11:28 PM EDT, Matthew Wilcox wrote:
> On Fri, Oct 23, 2026 at 10:32:26AM +0800, Yafang Shao wrote:
>> A successful migration frees the source folio, so the folio_nid() read
>> in the promotion counter update can pick up a reallocated page's nid.
>> Snapshot the nid before the migration, next to the memcg snapshot the
>> function already takes.
>
> I don't understand how a node ID can change even after the folio has
> been freed. I don't think this patch is wrong, but I don't think
I agree with you in the current code base.
> there's actually a bug here that's being fixed.
Strictly speaking, it can be seen as a benign UAF. It works, because
1. folio->flags happens to be the same as page->flags,
2. folio/page nid is stored in the ->flags and never changed.
In memdesc world, after a folio is freed, I assume folio->flags would be
zeroed since struct folio is freed and calling folio_nid() on a freed
folio would give a bogus result (yeah, it can be mitigated by not
zeroing node field and each node has its own struct folio pool, but that
makes folio_nid() implementation dependent).
IMHO, this patch is still worth getting in.
--
Best Regards,
Yan, Zi
next prev parent reply other threads:[~2026-10-23 14:11 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-23 2:32 [PATCH] mm/migrate: snapshot the source nid before the misplaced migration Yafang Shao
2026-10-23 3:28 ` Matthew Wilcox
2026-10-23 3:48 ` Yafang Shao
2026-10-23 14:11 ` Zi Yan [this message]
2026-10-25 3:51 ` Yafang Shao
2026-10-25 11:19 ` Matthew Wilcox
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=DMCA1N4UNM7G.3JBXJHJE6CQ7V@nvidia.com \
--to=ziy@nvidia.com \
--cc=akpm@linux-foundation.org \
--cc=apopple@nvidia.com \
--cc=byungchul@sk.com \
--cc=david@kernel.org \
--cc=gourry@gourry.net \
--cc=joshua.hahnjy@gmail.com \
--cc=laoar.shao@gmail.com \
--cc=linux-mm@kvack.org \
--cc=matthew.brost@intel.com \
--cc=willy@infradead.org \
--cc=ying.huang@intel.com \
--cc=ying.huang@linux.alibaba.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.