[PATCH OLK-6.6 0/2] gfp: include __GFP_NOWARN in GFP_NOWAIT

include __GFP_NOWARN in GFP_NOWAIT Dave Martin (1): docs/core-api: memory-allocation: GFP_NOWAIT doesn't need __GFP_NOWARN Matthew Wilcox (Oracle) (1): gfp: include __GFP_NOWARN in GFP_NOWAIT Documentation/core-api/memory-allocation.rst | 5 +++-- include/linux/gfp_types.h | 5 +++-- 2 files changed, 6 insertions(+), 4 deletions(-) -- 2.34.1

From: "Matthew Wilcox (Oracle)" <willy@infradead.org> mainline inclusion from mainline-v6.8-rc1 commit 16f5dfbc851b55b87101a20e181d4a14be3007d6 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IC9E4O Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i... -------------------------------- 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. Link: https://lkml.kernel.org/r/20231109211507.2262419-1-willy@infradead.org Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Kaixiong Yu <yukaixiong@huawei.com> --- 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 435a5a8a301e..af4015bc1b3f 100644 --- a/include/linux/gfp_types.h +++ b/include/linux/gfp_types.h @@ -283,7 +283,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. @@ -334,7 +335,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.34.1

From: Dave Martin <Dave.Martin@arm.com> mainline inclusion from mainline-v6.12-rc1 commit b745fdeff5398b108bbd1f8df19eba8e4b33fe77 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IC9E4O Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i... -------------------------------- 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 <Dave.Martin@arm.com> Reviewed-by: Matthew Wilcox (Oracle) <willy@infradead.org> Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Link: https://lore.kernel.org/r/20240729140127.244606-1-Dave.Martin@arm.com Signed-off-by: Kaixiong Yu <yukaixiong@huawei.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 1c58d883b273..e8c4a1a8ab44 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 -- 2.34.1

反馈: 您发送到kernel@openeuler.org的补丁/补丁集,已成功转换为PR! PR链接地址: https://gitee.com/openeuler/kernel/pulls/16364 邮件列表地址:https://mailweb.openeuler.org/archives/list/kernel@openeuler.org/message/KAK... FeedBack: The patch(es) which you have sent to kernel@openeuler.org mailing list has been converted to a pull request successfully! Pull request link: https://gitee.com/openeuler/kernel/pulls/16364 Mailing list address: https://mailweb.openeuler.org/archives/list/kernel@openeuler.org/message/KAK...
participants (2)
-
Kaixiong Yu
-
patchwork bot