From: Dave Martin Date: Mon, 29 Jul 2024 14:01:27 +0000 (+0100) Subject: docs/core-api: memory-allocation: GFP_NOWAIT doesn't need __GFP_NOWARN X-Git-Tag: v6.12-rc1~173^2~48 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=b745fdeff5398b108bbd1f8df19eba8e4b33fe77;p=thirdparty%2Fkernel%2Flinux.git 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 --- diff --git a/Documentation/core-api/memory-allocation.rst b/Documentation/core-api/memory-allocation.rst index 8b84eb4bdae7f..0f19dd5243239 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