[Question] Question about GFP_ATOMIC allocations on PREEMPT_RT kernel

[Question] Question about GFP_ATOMIC allocations on PREEMPT_RT kernel

[Yeo Reum Yun]

Hi mm experts,

I have a (possibly silly) question regarding the use of memory allocation with GFP_ATOMIC.

According to the latest documentation in core-api/memory-allocation.html,
using GFP_ATOMIC is acceptable in interrupt handlers:

GFP_ATOMIC:
“(GFP_KERNEL | __GFP_HIGH) & ~__GFP_DIRECT_RECLAIM (aka GFP_ATOMIC) –
non-sleeping allocation with an expensive fallback,
so it can access some portion of memory reserves.
Usually used from interrupt/bottom-half context with an expensive slow path fallback.”

This makes sense on non-RT kernels, where spin_lock() is non-sleepable.

However, how does this behave on a PREEMPT_RT kernel?

From what I see in the buddy allocator, even allocations using GFP_ATOMIC
can potentially sleep, since some of the locks used (e.g., zone->lock)
are implemented as sleepable rtmutex under PREEMPT_RT.

This seems fine for most interrupt handlers, since on PREEMPT_RT,
they are handled in dedicated IRQ threads — which means they run in a sleepable context.

But what about interrupt handlers registered with IRQF_NO_THREAD?

Those handlers run in hard interrupt context, which is non-sleepable.
If an allocation with GFP_ATOMIC involves a sleepable lock (like zone->lock),
wouldn’t that be problematic?

To my knowledge, it’s not clearly documented whether memory allocation functions like
kmalloc(), alloc_pages(), or folio_alloc() are explicitly forbidden in truly
non-sleepable contexts under PREEMPT_RT.

So my question is:
Is it always safe to call GFP_ATOMIC allocations from a non-sleepable context, regardless of the kernel configuration (i.e., RT vs non-RT)?

Thanks!
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

Re: [Question] Question about GFP_ATOMIC allocations on PREEMPT_RT kernel

[Harry Yoo]

On Sun, Jun 08, 2025 at 01:33:14PM +0000, Yeo Reum Yun wrote:
> Hi mm experts,
> 
> I have a (possibly silly) question regarding the use of memory allocation with GFP_ATOMIC.
> 
> According to the latest documentation in core-api/memory-allocation.html,
> using GFP_ATOMIC is acceptable in interrupt handlers:
> 
> GFP_ATOMIC:
> “(GFP_KERNEL | __GFP_HIGH) & ~__GFP_DIRECT_RECLAIM (aka GFP_ATOMIC) –
> non-sleeping allocation with an expensive fallback,
> so it can access some portion of memory reserves.
> Usually used from interrupt/bottom-half context with an expensive slow path fallback.”
> 
> This makes sense on non-RT kernels, where spin_lock() is non-sleepable.
> 
> However, how does this behave on a PREEMPT_RT kernel?
> 
> From what I see in the buddy allocator, even allocations using GFP_ATOMIC
> can potentially sleep, since some of the locks used (e.g., zone->lock)
> are implemented as sleepable rtmutex under PREEMPT_RT.
> 
> This seems fine for most interrupt handlers, since on PREEMPT_RT,
> they are handled in dedicated IRQ threads — which means they run in a sleepable context.
> 
> But what about interrupt handlers registered with IRQF_NO_THREAD?

You're not supposed allocate (even with GFP_ATOMIC) or free memory on
PREEMPT_RT in non-threaded interrupt context [1].

I think it somwhow implied in [2]? (Ok, probably not that obvious)

"Acquiring a raw_spinlock_t disables preemption and possibly also
interrupts, so the critical section must avoid acquiring a regular
spinlock_t or rwlock_t, for example, the critical section must avoid
allocating memory."

"But this code fails on PREEMPT_RT kernels because the memory allocator
is fully preemptible and therefore cannot be invoked from truly atomic
contexts."

[1] https://lore.kernel.org/linux-mm/YwZSUpYY9l442Lxr@linutronix.de

[2] https://www.kernel.org/doc/html/latest/locking/locktypes.html#raw-spinlock-t-on-rt

> Those handlers run in hard interrupt context, which is non-sleepable.
> If an allocation with GFP_ATOMIC involves a sleepable lock (like zone->lock),
> wouldn’t that be problematic?
> 
> To my knowledge, it’s not clearly documented whether memory allocation functions like
> kmalloc(), alloc_pages(), or folio_alloc() are explicitly forbidden in truly
> non-sleepable contexts under PREEMPT_RT.
> 
> So my question is:
> Is it always safe to call GFP_ATOMIC allocations from a non-sleepable context, regardless of the kernel configuration (i.e., RT vs non-RT)?
> 
> Thanks!
> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
> 

-- 
Cheers,
Harry / Hyeonggon

Re: [Question] Question about GFP_ATOMIC allocations on PREEMPT_RT kernel

[Yeoreum Yun]

Hi Harry,

[...]
>
> You're not supposed allocate (even with GFP_ATOMIC) or free memory on
> PREEMPT_RT in non-threaded interrupt context [1].
>
> I think it somwhow implied in [2]? (Ok, probably not that obvious)
>
> "Acquiring a raw_spinlock_t disables preemption and possibly also
> interrupts, so the critical section must avoid acquiring a regular
> spinlock_t or rwlock_t, for example, the critical section must avoid
> allocating memory."
>
> "But this code fails on PREEMPT_RT kernels because the memory allocator
> is fully preemptible and therefore cannot be invoked from truly atomic
> contexts."
>
> [1] https://lore.kernel.org/linux-mm/YwZSUpYY9l442Lxr@linutronix.de
>
> [2] https://www.kernel.org/doc/html/latest/locking/locktypes.html#raw-spinlock-t-on-rt
>

Thanks for clear reference :D
I miss the clause of [2]...

--
Sincerely,
Yeoreum Yun
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.