From: "Harry Yoo (Oracle)" <42.hyeyoo@gmail.com>
To: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Cc: linux-kernel@vger.kernel.org, osalvador@suse.de,
byungchul@sk.com, dave.hansen@linux.intel.com, luto@kernel.org,
peterz@infradead.org, akpm@linux-foundation.org,
max.byungchul.park@sk.com, max.byungchul.park@gmail.com
Subject: Re: [PATCH 1/1] x86/vmemmap: Use direct-mapped VA instead of vmemmap-based VA
Date: Tue, 18 Feb 2025 14:27:27 +0900 [thread overview]
Message-ID: <Z7QaPwI1eMPEwHii@MacBook-Air-5.local> (raw)
In-Reply-To: <20250217114133.400063-2-gwan-gyeong.mun@intel.com>
On Mon, Feb 17, 2025 at 01:41:33PM +0200, Gwan-gyeong Mun wrote:
> When a process leads the addition of a struct page to vmemmap
> (e.g. hot-plug), the page table update for the newly added vmemmap-based
> virtual address is updated first in init_mm's page table and then
> synchronized later.
>
> If the vmemmap-based virtual address is accessed through the process's
> page table before this sync, a page fault will occur.
>
> This translates vmemmap-based virtual address to direct-mapped virtual
> address and use it, if the current top-level page table is not init_mm's
> page table when accessing a vmemmap-based virtual address before this sync.
>
> Fixes: faf1c0008a33 ("x86/vmemmap: optimize for consecutive sections in partial populated PMDs")
> Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
> Cc: Oscar Salvador <osalvador@suse.de>
> Cc: Hyeonggon Yoo <42.hyeyoo@gmail.com>
I think this fix is reasonable without changing existing code too much.
Any thoughts from x86 folks?
> Cc: Byungchul Park <byungchul@sk.com>
> Cc: Dave Hansen <dave.hansen@linux.intel.com>
> Cc: Andy Lutomirski <luto@kernel.org>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Andrew Morton <akpm@linux-foundation.org>
Shouldn't we add Cc: <stable@vger.kernel.org>?
--
Harry
> ---
> arch/x86/mm/init_64.c | 17 ++++++++++++++---
> 1 file changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
> index 01ea7c6df303..1cb26f692831 100644
> --- a/arch/x86/mm/init_64.c
> +++ b/arch/x86/mm/init_64.c
> @@ -844,6 +844,17 @@ void __init paging_init(void)
> */
> static unsigned long unused_pmd_start __meminitdata;
>
> +static void * __meminit vmemmap_va_to_kaddr(unsigned long vmemmap_va)
> +{
> + void *kaddr = (void *)vmemmap_va;
> + pgd_t *pgd = __va(read_cr3_pa());
> +
> + if (init_mm.pgd != pgd)
> + kaddr = __va(slow_virt_to_phys(kaddr));
> +
> + return kaddr;
> +}
> +
> static void __meminit vmemmap_flush_unused_pmd(void)
> {
> if (!unused_pmd_start)
> @@ -851,7 +862,7 @@ static void __meminit vmemmap_flush_unused_pmd(void)
> /*
> * Clears (unused_pmd_start, PMD_END]
> */
> - memset((void *)unused_pmd_start, PAGE_UNUSED,
> + memset(vmemmap_va_to_kaddr(unused_pmd_start), PAGE_UNUSED,
> ALIGN(unused_pmd_start, PMD_SIZE) - unused_pmd_start);
> unused_pmd_start = 0;
> }
> @@ -882,7 +893,7 @@ static void __meminit __vmemmap_use_sub_pmd(unsigned long start)
> * case the first memmap never gets initialized e.g., because the memory
> * block never gets onlined).
> */
> - memset((void *)start, 0, sizeof(struct page));
> + memset(vmemmap_va_to_kaddr(start), 0, sizeof(struct page));
> }
>
> static void __meminit vmemmap_use_sub_pmd(unsigned long start, unsigned long end)
> @@ -924,7 +935,7 @@ static void __meminit vmemmap_use_new_sub_pmd(unsigned long start, unsigned long
> * Mark with PAGE_UNUSED the unused parts of the new memmap range
> */
> if (!IS_ALIGNED(start, PMD_SIZE))
> - memset((void *)page, PAGE_UNUSED, start - page);
> + memset(vmemmap_va_to_kaddr(page), PAGE_UNUSED, start - page);
>
> /*
> * We want to avoid memset(PAGE_UNUSED) when populating the vmemmap of
> --
> 2.48.1
>
next prev parent reply other threads:[~2025-02-18 5:27 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-17 11:41 [PATCH 0/1] x86/vmemmap: " Gwan-gyeong Mun
2025-02-17 11:41 ` [PATCH 1/1] " Gwan-gyeong Mun
2025-02-18 5:27 ` Harry Yoo (Oracle) [this message]
2025-02-18 5:43 ` Andrew Morton
2025-02-18 10:02 ` Gwan-gyeong Mun
2025-03-06 3:46 ` Andrew Morton
2025-03-06 16:09 ` Dave Hansen
2025-03-07 8:56 ` Gwan-gyeong Mun
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=Z7QaPwI1eMPEwHii@MacBook-Air-5.local \
--to=42.hyeyoo@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=byungchul@sk.com \
--cc=dave.hansen@linux.intel.com \
--cc=gwan-gyeong.mun@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=max.byungchul.park@gmail.com \
--cc=max.byungchul.park@sk.com \
--cc=osalvador@suse.de \
--cc=peterz@infradead.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
all inboxes | Powered by JetHome®