From: "Li Zhe" <lizhe.67@bytedance.com>
To: <akpm@linux-foundation.org>, <apopple@nvidia.com>,
<arnd@arndb.de>, <balbirs@nvidia.com>, <bp@alien8.de>,
<dave.hansen@linux.intel.com>, <david@kernel.org>,
<kees@kernel.org>, <mingo@redhat.com>, <muchun.song@linux.dev>,
<rppt@kernel.org>, <tglx@kernel.org>
Cc: <linux-arch@vger.kernel.org>, <linux-hardening@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <linux-mm@kvack.org>,
<x86@kernel.org>, <lizhe.67@bytedance.com>
Subject: [PATCH v9 3/8] mm: add a set_page_section_from_pfn() helper
Date: Mon, 3 Aug 2026 15:09:24 +0800 [thread overview]
Message-ID: <20260803070929.86075-4-lizhe.67@bytedance.com> (raw)
In-Reply-To: <20260803070929.86075-1-lizhe.67@bytedance.com>
Callers that want to update section bits from a PFN currently need to
open-code:
set_page_section(page, pfn_to_section_nr(pfn));
and guard that sequence with #ifdef SECTION_IN_PAGE_FLAGS.
Add set_page_section_from_pfn() to wrap that update in one place. When
section bits are stored in page flags, the helper derives the section
number from the PFN and updates the page flags. Otherwise keep it as a
no-op so callers can use one helper without open-coding
SECTION_IN_PAGE_FLAGS.
Convert set_page_links() to use the new helper so later ZONE_DEVICE
fast-path patches can also update section bits without open-coding
SECTION_IN_PAGE_FLAGS at each callsite.
This keeps the PFN-to-section translation local to the configurations
that actually store section bits in struct page flags, and avoids
exposing that detail to generic callers.
No functional change intended.
Signed-off-by: Li Zhe <lizhe.67@bytedance.com>
Reviewed-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Acked-by: Muchun Song <muchun.song@linux.dev>
Reviewed-by: Balbir Singh <balbirs@nvidia.com>
---
include/linux/mm.h | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 485df9c2dbdd..43343bfce493 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2541,11 +2541,22 @@ static inline void set_page_section(struct page *page, unsigned long section)
page->flags.f |= (section & SECTIONS_MASK) << SECTIONS_PGSHIFT;
}
+static inline void set_page_section_from_pfn(struct page *page,
+ unsigned long pfn)
+{
+ set_page_section(page, pfn_to_section_nr(pfn));
+}
+
static inline unsigned long memdesc_section(memdesc_flags_t mdf)
{
return (mdf.f >> SECTIONS_PGSHIFT) & SECTIONS_MASK;
}
#else /* !SECTION_IN_PAGE_FLAGS */
+static inline void set_page_section_from_pfn(struct page *page,
+ unsigned long pfn)
+{
+}
+
static inline unsigned long memdesc_section(memdesc_flags_t mdf)
{
return 0;
@@ -2768,9 +2779,7 @@ static inline void set_page_links(struct page *page, enum zone_type zone,
{
set_page_zone(page, zone);
set_page_node(page, node);
-#ifdef SECTION_IN_PAGE_FLAGS
- set_page_section(page, pfn_to_section_nr(pfn));
-#endif
+ set_page_section_from_pfn(page, pfn);
}
/**
--
2.20.1
next prev parent reply other threads:[~2026-08-03 7:11 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-03 7:09 [PATCH v9 0/8] mm: optimize zone-device memmap initialization Li Zhe
2026-08-03 7:09 ` [PATCH v9 1/8] mm: fix stale ZONE_DEVICE refcount comment Li Zhe
2026-08-03 7:09 ` [PATCH v9 2/8] mm: factor zone-device page init helpers out of __init_zone_device_page Li Zhe
2026-08-03 7:09 ` Li Zhe [this message]
2026-08-03 7:09 ` [PATCH v9 4/8] mm: add a template-based fast path for zone-device page init Li Zhe
2026-08-03 8:39 ` Muchun Song
2026-08-05 9:50 ` Li Zhe
2026-08-03 7:09 ` [PATCH v9 5/8] mm: extend the template fast path to zone-device compound tails Li Zhe
2026-08-03 7:09 ` [PATCH v9 6/8] string: introduce memcpy_nontemporal() Li Zhe
2026-08-03 7:09 ` [PATCH v9 7/8] mm: use memcpy_nontemporal() in zone-device template copies Li Zhe
2026-08-03 7:09 ` [PATCH v9 8/8] x86/string: extend memcpy_flushcache() fixed-size fastpaths Li Zhe
2026-08-04 20:35 ` Borislav Petkov
2026-08-05 11:04 ` Li Zhe
2026-08-03 21:40 ` [PATCH v9 0/8] mm: optimize zone-device memmap initialization Andrew Morton
2026-08-05 9:49 ` Li Zhe
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=20260803070929.86075-4-lizhe.67@bytedance.com \
--to=lizhe.67@bytedance.com \
--cc=akpm@linux-foundation.org \
--cc=apopple@nvidia.com \
--cc=arnd@arndb.de \
--cc=balbirs@nvidia.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=david@kernel.org \
--cc=kees@kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mingo@redhat.com \
--cc=muchun.song@linux.dev \
--cc=rppt@kernel.org \
--cc=tglx@kernel.org \
--cc=x86@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox