diff mbox series

mm: clarify usage of GFP_ATOMIC in !preemptible contexts

Message ID 20200929123010.5137-1-mhocko@kernel.org (mailing list archive)
State New
Headers show
Series mm: clarify usage of GFP_ATOMIC in !preemptible contexts | expand

Commit Message

Michal Hocko Sept. 29, 2020, 12:30 p.m. UTC
From: Michal Hocko <mhocko@suse.com>

There is a general understanding that GFP_ATOMIC/GFP_NOWAIT are
to be used from atomic contexts. E.g. from within a spin lock or from
the IRQ context. This is correct but there are some atomic contexts
where the above doesn't hold. One of them would be an NMI context.
Page allocator has never supported that and the general fear of this
context didn't let anybody to actually even try to use the allocator
there. Good, but let's be more specific about that.

Another such a context, and that is where people seem to be more daring,
is raw_spin_lock. Mostly because it simply resembles regular spin lock
which is supported by the allocator and there is not any implementation
difference with !RT kernels in the first place. Be explicit that such
a context is not supported by the allocator. The underlying reason is
that zone->lock would have to become raw_spin_lock as well and that has
turned out to be a problem for RT
(http://lkml.kernel.org/r/87mu305c1w.fsf@nanos.tec.linutronix.de).

Signed-off-by: Michal Hocko <mhocko@suse.com>
---
 include/linux/gfp.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

Comments

David Hildenbrand Sept. 29, 2020, 1:29 p.m. UTC | #1
On 29.09.20 14:30, Michal Hocko wrote:
> From: Michal Hocko <mhocko@suse.com>
> 
> There is a general understanding that GFP_ATOMIC/GFP_NOWAIT are
> to be used from atomic contexts. E.g. from within a spin lock or from
> the IRQ context. This is correct but there are some atomic contexts
> where the above doesn't hold. One of them would be an NMI context.
> Page allocator has never supported that and the general fear of this
> context didn't let anybody to actually even try to use the allocator
> there. Good, but let's be more specific about that.
> 
> Another such a context, and that is where people seem to be more daring,
> is raw_spin_lock. Mostly because it simply resembles regular spin lock
> which is supported by the allocator and there is not any implementation
> difference with !RT kernels in the first place. Be explicit that such
> a context is not supported by the allocator. The underlying reason is
> that zone->lock would have to become raw_spin_lock as well and that has
> turned out to be a problem for RT
> (http://lkml.kernel.org/r/87mu305c1w.fsf@nanos.tec.linutronix.de).

Interesting

Reviewed-by: David Hildenbrand <david@redhat.com>
Thomas Gleixner Sept. 29, 2020, 7:55 p.m. UTC | #2
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>
Uladzislau Rezki Sept. 29, 2020, 8:33 p.m. UTC | #3
On Tue, Sep 29, 2020 at 02:30:10PM +0200, Michal Hocko wrote:
> From: Michal Hocko <mhocko@suse.com>
> 
> There is a general understanding that GFP_ATOMIC/GFP_NOWAIT are
> to be used from atomic contexts. E.g. from within a spin lock or from
> the IRQ context. This is correct but there are some atomic contexts
> where the above doesn't hold. One of them would be an NMI context.
> Page allocator has never supported that and the general fear of this
> context didn't let anybody to actually even try to use the allocator
> there. Good, but let's be more specific about that.
> 
> Another such a context, and that is where people seem to be more daring,
> is raw_spin_lock. Mostly because it simply resembles regular spin lock
> which is supported by the allocator and there is not any implementation
> difference with !RT kernels in the first place. Be explicit that such
> a context is not supported by the allocator. The underlying reason is
> that zone->lock would have to become raw_spin_lock as well and that has
> turned out to be a problem for RT
> (http://lkml.kernel.org/r/87mu305c1w.fsf@nanos.tec.linutronix.de).
> 
> Signed-off-by: Michal Hocko <mhocko@suse.com>
> ---
>  include/linux/gfp.h | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> 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.
> -- 
> 2.28.0
> 

Reviewed-by: Uladzislau Rezki <urezki@gmail.com>
diff mbox series

Patch

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.