All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yeoreum Yun <yeoreum.yun@arm.com>
To: Will Deacon <will@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-rt-devel@lists.linux.dev,
	catalin.marinas@arm.com, ryan.roberts@arm.com,
	akpm@linux-oundation.org, david@kernel.org,
	kevin.brodsky@arm.com, quic_zhenhuah@quicinc.com,
	dev.jain@arm.com, yang@os.amperecomputing.com,
	chaitanyas.prakash@arm.com, bigeasy@linutronix.de,
	clrkwllms@kernel.org, rostedt@goodmis.org,
	lorenzo.stoakes@oracle.com, ardb@kernel.org, jackmanb@google.com,
	vbabka@suse.cz, mhocko@suse.com
Subject: Re: [PATCH v5 3/3] arm64: mmu: avoid allocating pages while installing ng-mapping for KPTI
Date: Mon, 19 Jan 2026 21:30:30 +0000	[thread overview]
Message-ID: <aW6idotkGVoD692c@e129823.arm.com> (raw)
In-Reply-To: <aW5qfh_bsGNRd0Vd@willie-the-truck>

Hi Will,

> On Mon, Jan 05, 2026 at 08:23:28PM +0000, Yeoreum Yun wrote:
> > The current __kpti_install_ng_mappings() allocates a temporary PGD
> > while installing the NG mapping for KPTI under stop_machine(),
> > using GFP_ATOMIC.
> >
> > This is fine in the non-PREEMPT_RT case. However, it becomes a problem
> > under PREEMPT_RT because generic memory allocation/free APIs
> > (e.g., pgtable_alloc(), __get_free_pages(), etc.) cannot be invoked
> > in a non-preemptible context, except for the *_nolock() variants.
> > These generic allocators may sleep due to their use of spin_lock().
> >
> > In other words, calling __get_free_pages(), even with GFP_ATOMIC,
> > is not allowed in __kpti_install_ng_mappings(), which is executed by
> > the stopper thread where preemption is disabled under PREEMPT_RT.
> >
> > To address this, preallocate the page needed for the temporary PGD
> > before invoking __kpti_install_ng_mappings() via stop_machine().
> >
> > Fixes: 47546a1912fc ("arm64: mm: install KPTI nG mappings with MMU enabled")
> > Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
> > Reviewed-by: Ryan Roberts <ryan.roberts@arm.com>
> > ---
> >  arch/arm64/mm/mmu.c | 21 ++++++++++++---------
> >  1 file changed, 12 insertions(+), 9 deletions(-)
> >
> > diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> > index 120874a2d35b..6ea5b80ab54f 100644
> > --- a/arch/arm64/mm/mmu.c
> > +++ b/arch/arm64/mm/mmu.c
> > @@ -1360,7 +1360,7 @@ static phys_addr_t __init kpti_ng_pgd_alloc(enum pgtable_type type)
> >  	return kpti_ng_temp_alloc;
> >  }
> >
> > -static int __init __kpti_install_ng_mappings(void *__unused)
> > +static int __init __kpti_install_ng_mappings(void *data)
> >  {
> >  	typedef void (kpti_remap_fn)(int, int, phys_addr_t, unsigned long);
> >  	extern kpti_remap_fn idmap_kpti_install_ng_mappings;
> > @@ -1368,10 +1368,9 @@ static int __init __kpti_install_ng_mappings(void *__unused)
> >
> >  	int cpu = smp_processor_id();
> >  	int levels = CONFIG_PGTABLE_LEVELS;
> > -	int order = order_base_2(levels);
> >  	u64 kpti_ng_temp_pgd_pa = 0;
> >  	pgd_t *kpti_ng_temp_pgd;
> > -	u64 alloc = 0;
> > +	u64 alloc = *(u64 *)data;
> >
> >  	if (levels == 5 && !pgtable_l5_enabled())
> >  		levels = 4;
> > @@ -1382,8 +1381,6 @@ static int __init __kpti_install_ng_mappings(void *__unused)
> >
> >  	if (!cpu) {
> >  		int ret;
> > -
> > -		alloc = __get_free_pages(GFP_ATOMIC | __GFP_ZERO, order);
> >  		kpti_ng_temp_pgd = (pgd_t *)(alloc + (levels - 1) * PAGE_SIZE);
> >  		kpti_ng_temp_alloc = kpti_ng_temp_pgd_pa = __pa(kpti_ng_temp_pgd);
> >
> > @@ -1414,16 +1411,16 @@ static int __init __kpti_install_ng_mappings(void *__unused)
> >  	remap_fn(cpu, num_online_cpus(), kpti_ng_temp_pgd_pa, KPTI_NG_TEMP_VA);
> >  	cpu_uninstall_idmap();
> >
> > -	if (!cpu) {
> > -		free_pages(alloc, order);
> > +	if (!cpu)
> >  		arm64_use_ng_mappings = true;
> > -	}
> >
> >  	return 0;
> >  }
> >
> >  void __init kpti_install_ng_mappings(void)
> >  {
> > +	int order = order_base_2(CONFIG_PGTABLE_LEVELS);
> > +	u64 alloc;
> >  	/* Check whether KPTI is going to be used */
> >  	if (!arm64_kernel_unmapped_at_el0())
> >  		return;
> > @@ -1436,8 +1433,14 @@ void __init kpti_install_ng_mappings(void)
> >  	if (arm64_use_ng_mappings)
> >  		return;
> >
> > +	alloc = __get_free_pages(GFP_KERNEL | __GFP_ZERO, order);
> > +	if (!alloc)
> > +		panic("Failed to alloc page tables\n");
>
> Why are you adding this panic?

Because original code call the panic() when it fails to create
mapping of kpti_ng_temp_pgd and I think allocation is also part
of creating kpti_ng_temp_pgd too.
So, I added this panic() when allocation is failed for kpti_ng_temp_pgd.

--
Sincerely,
Yeoreum Yun


  reply	other threads:[~2026-01-19 21:33 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-05 20:23 [PATCH v5 0/3] fix wrong usage of memory allocation APIs under PREEMPT_RT in arm64 Yeoreum Yun
2026-01-05 20:23 ` [PATCH v5 1/3] arm64: mmu: introduce pgtable_alloc_t Yeoreum Yun
2026-01-05 20:23 ` [PATCH v5 2/3] arm64: mmu: avoid allocating pages while splitting the linear mapping Yeoreum Yun
2026-01-19 17:28   ` Will Deacon
2026-01-19 21:24     ` Yeoreum Yun
2026-01-20  8:56       ` Ryan Roberts
2026-01-20  9:29         ` Yeoreum Yun
2026-01-20 10:40           ` Ryan Roberts
2026-01-20 10:54             ` Yeoreum Yun
2026-01-20 15:53             ` Will Deacon
2026-01-20 16:16               ` Yeoreum Yun
2026-01-20 16:22               ` Ryan Roberts
2026-01-20 16:31                 ` Yeoreum Yun
2026-01-20 17:35                   ` Ryan Roberts
2026-01-20 17:49                     ` Yeoreum Yun
2026-01-21  0:12                     ` Yang Shi
2026-01-21  8:32                       ` Yeoreum Yun
2026-01-21 10:20                         ` Ryan Roberts
2026-01-21 11:30                           ` Yeoreum Yun
2026-01-21 22:57                           ` Yang Shi
2026-01-22  7:42                             ` Yeoreum Yun
2026-01-22 13:47                               ` Ryan Roberts
2026-01-20 22:24           ` Yang Shi
2026-01-20 23:01             ` Yeoreum Yun
2026-01-21  0:43               ` Yang Shi
2026-01-21  8:15                 ` Yeoreum Yun
2026-01-05 20:23 ` [PATCH v5 3/3] arm64: mmu: avoid allocating pages while installing ng-mapping for KPTI Yeoreum Yun
2026-01-19 17:31   ` Will Deacon
2026-01-19 21:30     ` Yeoreum Yun [this message]
2026-01-20 11:44       ` Will Deacon
2026-01-20 15:30         ` Yeoreum Yun

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=aW6idotkGVoD692c@e129823.arm.com \
    --to=yeoreum.yun@arm.com \
    --cc=akpm@linux-oundation.org \
    --cc=ardb@kernel.org \
    --cc=bigeasy@linutronix.de \
    --cc=catalin.marinas@arm.com \
    --cc=chaitanyas.prakash@arm.com \
    --cc=clrkwllms@kernel.org \
    --cc=david@kernel.org \
    --cc=dev.jain@arm.com \
    --cc=jackmanb@google.com \
    --cc=kevin.brodsky@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rt-devel@lists.linux.dev \
    --cc=lorenzo.stoakes@oracle.com \
    --cc=mhocko@suse.com \
    --cc=quic_zhenhuah@quicinc.com \
    --cc=rostedt@goodmis.org \
    --cc=ryan.roberts@arm.com \
    --cc=vbabka@suse.cz \
    --cc=will@kernel.org \
    --cc=yang@os.amperecomputing.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.