Message ID | 20231109211507.2262419-1-willy@infradead.org (mailing list archive) |
---|---|
State | New |
Headers | show |
Series | gfp: Include __GFP_NOWARN in GFP_NOWAIT | expand |
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.
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)
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(-)