Messages in this thread | | | From | Thomas Gleixner <> | Subject | Re: [PATCH] mm: clarify usage of GFP_ATOMIC in !preemptible contexts | Date | Tue, 29 Sep 2020 21:55:45 +0200 |
| |
On Tue, Sep 29 2020 at 14:30, Michal Hocko wrote: > diff --git a/include/linux/gfp.h b/include/linux/gfp.h > index 67a0774e080b..2e8370cf60c7 100644 > --- a/include/linux/gfp.h > +++ b/include/linux/gfp.h > @@ -238,7 +238,9 @@ struct vm_area_struct; > * %__GFP_FOO flags as necessary. > * > * %GFP_ATOMIC users can not sleep and need the allocation to succeed. A lower > - * watermark is applied to allow access to "atomic reserves" > + * 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. > * > * %GFP_KERNEL is typical for kernel-internal allocations. The caller requires > * %ZONE_NORMAL or a lower zone for direct access but can direct reclaim.
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
| |