Re: [PATCH 0/2] introduce pagetable_alloc_nolock()

[Yeoreum Yun <yeoreum.yun@arm.com>]

[...]

> > Note this is explained in Documentation/core-api/real-time/differences.rst:
> >
> > Memory allocation
> > -----------------
> >
> > The memory allocation APIs, such as kmalloc() and alloc_pages(), require a
> > gfp_t flag to indicate the allocation context. On non-PREEMPT_RT kernels, it is
> > necessary to use GFP_ATOMIC when allocating memory from interrupt context or
> > from sections where preemption is disabled. This is because the allocator must
> > not sleep in these contexts waiting for memory to become available.
> >
> > However, this approach does not work on PREEMPT_RT kernels. The memory
> > allocator in PREEMPT_RT uses sleeping locks internally, which cannot be
> > acquired when preemption is disabled. Fortunately, this is generally not a
> > problem, because PREEMPT_RT moves most contexts that would traditionally run
> > with preemption or interrupts disabled into threaded context, where sleeping is
> > allowed.
> >
> > What remains problematic is code that explicitly disables preemption or
> > interrupts. In such cases, memory allocation must be performed outside the
> > critical section.
> >
> > This restriction also applies to memory deallocation routines such as kfree()
> > and free_pages(), which may also involve internal locking and must not be
> > called from non-preemptible contexts.
>
> Oh, thanks for pointing to that, I had never read that before (oops).
>
> Shall we point to this from the doc-comment? Something like the below.
>
> BTW, Yeorum, assuming you care about PREEMPT_RT, maybe you can get
> Sparse to find some other bugs of this nature? Or if not, plain old
> Coccinelle would probably find a few.

That's good idea. I'll try to sparse later.

Although this is a slightly different topic, based on Ryan’s suggestion,
I plan to address this misuse on arm64 by switching to pre-allocated pages.
As a result, I will remove the pgtable_alloc_nolock() interface.

> From 4c6b4d4cb08aee9559d02a348b9ecf799142c96f Mon Sep 17 00:00:00 2001
> From: Brendan Jackman <jackmanb@google.com>
> Date: Wed, 17 Dec 2025 13:26:28 +0000
> Subject: [PATCH] mm: clarify GFP_ATOMIC/GFP_NOWAIT doc-comment
>
> The current description of contexts where it's invalid to make
> GFP_ATOMIC and GFP_NOWAIT calls is rather vague.
>
> Replace this with a direct description of the actual contexts of concern
> and refer to the RT docs where this is explained more discursively.
>
> While rejigging this prose, also move the documentation of GFP_NOWAIT to
> the GFP_NOWAIT section.
>
> Link: https://lore.kernel.org/all/d912480a-5229-4efe-9336-b31acded30f5@suse.cz/
> Signed-off-by: Brendan Jackman <jackmanb@google.com>
> ---
>  include/linux/gfp_types.h | 7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/gfp_types.h b/include/linux/gfp_types.h
> index 3de43b12209ee..07a378542caf2 100644
> --- a/include/linux/gfp_types.h
> +++ b/include/linux/gfp_types.h
> @@ -309,8 +309,10 @@ enum {
>   *
>   * %GFP_ATOMIC users can not sleep and need the allocation to succeed. A lower
>   * watermark is applied to allow access to "atomic reserves".
> - * The current implementation doesn't support NMI and few other strict
> - * non-preemptive contexts (e.g. raw_spin_lock). The same applies to %GFP_NOWAIT.
> + * The current implementation doesn't support NMI, nor contexts that disable
> + * preemption under PREEMPT_RT. This includes raw_spin_lock() and plain
> + * preempt_disable() - see Documentation/core-api/real-time/differences.rst for
> + * more info.
>   *
>   * %GFP_KERNEL is typical for kernel-internal allocations. The caller requires
>   * %ZONE_NORMAL or a lower zone for direct access but can direct reclaim.
> @@ -321,6 +323,7 @@ enum {
>   * %GFP_NOWAIT is for kernel allocations that should not stall for direct
>   * reclaim, start physical IO or use any filesystem callback.  It is very
>   * likely to fail to allocate memory, even for very small allocations.
> + * The same restrictions on calling contexts apply as for %GFP_ATOMIC.
>   *
>   * %GFP_NOIO will use direct reclaim to discard clean pages or slab pages
>   * that do not require the starting of any physical IO.
> --
> 2.50.1

This patch looks good to me. Feel free to add:

Reviewed-by: Yeoreum Yun <yeoreum.yun@arm.com>

--
Sincerely,
Yeoreum Yun