From: Ryan Roberts <ryan.roberts@arm.com>
To: Vlastimil Babka <vbabka@suse.cz>,
Yeoreum Yun <yeoreum.yun@arm.com>,
catalin.marinas@arm.com, will@kernel.org,
akpm@linux-foundation.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
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-rt-devel@lists.linux.dev
Subject: Re: [PATCH v2 2/2] arm64: mmu: avoid allocating pages while installing ng-mapping for KPTI
Date: Thu, 18 Dec 2025 08:32:06 +0000 [thread overview]
Message-ID: <d4dce109-8e02-488b-8ede-ef568f7262be@arm.com> (raw)
In-Reply-To: <586d24f9-a54d-4c14-bd25-fed18423d709@suse.cz>
On 18/12/2025 07:51, Vlastimil Babka wrote:
> On 12/17/25 20:03, Ryan Roberts wrote:
>> On 17/12/2025 18:20, 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>
>>> ---
>>> arch/arm64/mm/mmu.c | 22 +++++++++++++---------
>>> 1 file changed, 13 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
>>> index e4e6c7e0a016..69d9651de0cd 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,17 @@ 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 +1434,14 @@ void __init kpti_install_ng_mappings(void)
>>> if (arm64_use_ng_mappings)
>>> return;
>>>
>>> + alloc = __get_free_pages(GFP_ATOMIC | __GFP_ZERO, order);
>>
>> I don't think this requires GFP_ATOMIC now?
>
> Do you mean it's fine to use GFP_KERNEL now, or still not, and you mean that
> GFP_NOWAIT is sufficient?
I mean it's fine to use "GFP_KERNEL | __GFP_ZERO"; this context can sleep so we
don't want to dip into the reserves - we can sleep and reclaim if needed.
>
>> With that removed:
>>
>> Reviewed-by: Ryan Roberts <ryan.roberts@arm.com>
>>
>>> + if (!alloc)
>>> + panic("Failed to alloc page tables\n");
>>> +
>>> init_idmap_kpti_bbml2_flag();
>>> - stop_machine(__kpti_install_ng_mappings, NULL, cpu_online_mask);
>>> + stop_machine(__kpti_install_ng_mappings, &alloc, cpu_online_mask);
>>> +
>>> + free_pages(alloc, order);
>>> }
>>>
>>> static pgprot_t __init kernel_exec_prot(void)
>>
>
prev parent reply other threads:[~2025-12-18 8:32 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-17 18:20 [PATCH v2 0/2] fix wrong usage of memory allocation APIs under PREEMPT_RT in arm64 Yeoreum Yun
2025-12-17 18:20 ` [PATCH v2 1/2] arm64: mmu: don't allocate page while spliting linear mapping Yeoreum Yun
2025-12-18 8:23 ` David Hildenbrand (Red Hat)
2025-12-18 9:08 ` Yeoreum Yun
2025-12-18 14:22 ` Ryan Roberts
2025-12-18 15:01 ` Yeoreum Yun
2025-12-18 15:42 ` Ryan Roberts
2025-12-18 15:54 ` Yeoreum Yun
2025-12-17 18:20 ` [PATCH v2 2/2] arm64: mmu: avoid allocating pages while installing ng-mapping for KPTI Yeoreum Yun
2025-12-17 19:03 ` Ryan Roberts
2025-12-17 19:09 ` Yeoreum Yun
2025-12-18 8:34 ` Ryan Roberts
2025-12-18 8:37 ` Yeoreum Yun
2025-12-18 8:46 ` David Hildenbrand (Red Hat)
2025-12-18 9:31 ` Yeoreum Yun
2025-12-18 9:41 ` David Hildenbrand (Red Hat)
2025-12-18 10:07 ` Yeoreum Yun
2025-12-18 7:51 ` Vlastimil Babka
2025-12-18 8:32 ` Ryan Roberts [this message]
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=d4dce109-8e02-488b-8ede-ef568f7262be@arm.com \
--to=ryan.roberts@arm.com \
--cc=akpm@linux-foundation.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=quic_zhenhuah@quicinc.com \
--cc=rostedt@goodmis.org \
--cc=vbabka@suse.cz \
--cc=will@kernel.org \
--cc=yang@os.amperecomputing.com \
--cc=yeoreum.yun@arm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox