From b745fdeff5398b108bbd1f8df19eba8e4b33fe77 Mon Sep 17 00:00:00 2001 From: Dave Martin Date: Mon, 29 Jul 2024 15:01:27 +0100 Subject: [PATCH] docs/core-api: memory-allocation: GFP_NOWAIT doesn't need __GFP_NOWARN Since v6.8 the definition of GFP_NOWAIT has implied __GFP_NOWARN, so it is now redundant to add this flag explicitly. Update the docs to match, and emphasise the need for a fallback when using GFP_NOWAIT. Fixes: 16f5dfbc851b ("gfp: include __GFP_NOWARN in GFP_NOWAIT") Signed-off-by: Dave Martin Reviewed-by: Matthew Wilcox (Oracle) Acked-by: Mike Rapoport (Microsoft) Signed-off-by: Jonathan Corbet Link: https://lore.kernel.org/r/20240729140127.244606-1-Dave.Martin@arm.com --- Documentation/core-api/memory-allocation.rst | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/Documentation/core-api/memory-allocation.rst b/Documentation/core-api/memory-allocation.rst index 8b84eb4bdae7..0f19dd524323 100644 --- a/Documentation/core-api/memory-allocation.rst +++ b/Documentation/core-api/memory-allocation.rst @@ -45,8 +45,9 @@ here we briefly outline their recommended usage: * If the allocation is performed from an atomic context, e.g interrupt handler, use ``GFP_NOWAIT``. This flag prevents direct reclaim and IO or filesystem operations. Consequently, under memory pressure - ``GFP_NOWAIT`` allocation is likely to fail. Allocations which - have a reasonable fallback should be using ``GFP_NOWARN``. + ``GFP_NOWAIT`` allocation is likely to fail. Users of this flag need + to provide a suitable fallback to cope with such failures where + appropriate. * If you think that accessing memory reserves is justified and the kernel will be stressed unless allocation succeeds, you may use ``GFP_ATOMIC``. * Untrusted allocations triggered from userspace should be a subject