[PATCH] gfp: Include __GFP_NOWARN in GFP_NOWAIT

[PATCH] gfp: Include __GFP_NOWARN in GFP_NOWAIT

[Matthew Wilcox (Oracle)]

GFP_NOWAIT callers are always prepared for their allocations to fail
because they fail so frequently.  Forcing the callers to remember to add
__GFP_NOWARN is just annoying and leads to an endless stream of patches
for the places where we forgot to add it.

We can now remove __GFP_NOWARN from all the callers which specify
GFP_NOWAIT, but I'd rather wait a cycle and send patches to each
maintainer instead of creating a big pile of merge conflicts.

Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
---
 include/linux/gfp_types.h | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/include/linux/gfp_types.h b/include/linux/gfp_types.h
index 6583a58670c5..ae994534a12a 100644
--- a/include/linux/gfp_types.h
+++ b/include/linux/gfp_types.h
@@ -274,7 +274,8 @@ typedef unsigned int __bitwise gfp_t;
  * accounted to kmemcg.
  *
  * %GFP_NOWAIT is for kernel allocations that should not stall for direct
- * reclaim, start physical IO or use any filesystem callback.
+ * reclaim, start physical IO or use any filesystem callback.  It is very
+ * likely to fail to allocate memory, even for very small allocations.
  *
  * %GFP_NOIO will use direct reclaim to discard clean pages or slab pages
  * that do not require the starting of any physical IO.
@@ -325,7 +326,7 @@ typedef unsigned int __bitwise gfp_t;
 #define GFP_ATOMIC	(__GFP_HIGH|__GFP_KSWAPD_RECLAIM)
 #define GFP_KERNEL	(__GFP_RECLAIM | __GFP_IO | __GFP_FS)
 #define GFP_KERNEL_ACCOUNT (GFP_KERNEL | __GFP_ACCOUNT)
-#define GFP_NOWAIT	(__GFP_KSWAPD_RECLAIM)
+#define GFP_NOWAIT	(__GFP_KSWAPD_RECLAIM | __GFP_NOWARN)
 #define GFP_NOIO	(__GFP_RECLAIM)
 #define GFP_NOFS	(__GFP_RECLAIM | __GFP_IO)
 #define GFP_USER	(__GFP_RECLAIM | __GFP_IO | __GFP_FS | __GFP_HARDWALL)
-- 
2.42.0

Re: [PATCH] gfp: Include __GFP_NOWARN in GFP_NOWAIT

[Andrew Morton]

On Thu,  9 Nov 2023 21:15:07 +0000 "Matthew Wilcox (Oracle)" <willy@infradead.org> wrote:

> GFP_NOWAIT callers are always prepared for their allocations to fail
> because they fail so frequently.  Forcing the callers to remember to add
> __GFP_NOWARN is just annoying and leads to an endless stream of patches
> for the places where we forgot to add it.

A possible problem is call sites where the developers were relying upon
the core MM's warning, so they chose to omit __GFP_NOWARN rather than
adding a local printk.

We're now silencing core MM's warning so those developers might lose
some diagnostic information.

Random example, arch/s390/pci/pci_clp.c:clp_refresh_fh().  After this
change, the pci_clp developers won't see (or be told about) allocation
failures in this function.  If they know about this change, they may
now choose to add a local printk.

It's not the end of the world by any means.  One possible way to
prevent this change in behavior is to add a new __GFP_WARN and go add
it to all the sites which use bare __GFP_NOWAIT and which do not have a
local printk for the allocation failure.