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: x86/vmemmap: Use direct-mapped VA instead of vmemmap-based VA 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 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.