mm: adjust out-dated document of __GFP_NOFAIL
Subsystems (3)
PATCH v2 1/1 mm: adjust out-dated document of __GFP_NOFAIL
Commit ee040cbd6e48 ("mm/page_alloc: don't warn about large allocations with __GFP_NOFAIL") remove a warning on allocating large folio with __GFP_NOFAIL, which was placed there by commit 903edea6c53f ("mm: warn about illegal __GFP_NOFAIL usage in a more appropriate location and manner").
While in that commit, it also documented this behavior which is out-dated now.
Adjust the document to align to current code, and adjust the comment while at it.
---
v2:
* s/is adjusted/was placed there/ in change log
* instead of removing the document, say "is discouraged"
v1: https://lore.kernel.org/all/[email protected]/T/#u
--- include/linux/gfp_types.h | 2 +- mm/page_alloc.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
include/linux/gfp_types.h +1 -1
@@ -244,7 +244,7 @@ enum {* definitely preferable to use the flag rather than opencode endless * loop around allocator. * Allocating pages from the buddy with __GFP_NOFAIL and order > 1 is -* not supported. Please consider using kvmalloc() instead. +* discouraged. Please consider using kvmalloc() instead if possible. */ #define __GFP_IO ((__force gfp_t)___GFP_IO)#define __GFP_FS ((__force gfp_t)___GFP_FS)
mm/page_alloc.c +1 -1
@@ -4804,7 +4804,7 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order,if (unlikely (nofail)) {/* -* Also we don't support __GFP_NOFAIL without __GFP_DIRECT_RECLAIM, +* We don't support __GFP_NOFAIL without __GFP_DIRECT_RECLAIM, * otherwise, we may result in lockup. */ WARN_ON_ONCE (!can_direct_reclaim);
Signature · 1 line
2.34.1
Quoted 6 lines · Wei Yang
Commit
ee040cbd6e48("mm/page_alloc: don't warn about large allocations with__GFP_NOFAIL") remove a warning on allocating large folio with__GFP_NOFAIL, which was placed there by commit903edea6c53f("mm: warn about illegal__GFP_NOFAILusage in a more appropriate location and manner").
Quoted 7 lines
While in that commit, it also documented this behavior which is out-dated now.
Adjust the document to align to current code, and adjust the comment while at it.
Signed-off-by Wei Yang <[email protected]>
Quoted 38 lines
---
v2:
* s/is adjusted/was placed there/ in change log
* instead of removing the document, say "is discouraged"v1: https://lore.kernel.org/all/[email protected]/T/#u
--- include/linux/gfp_types.h | 2 +- mm/page_alloc.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)include/linux/gfp_types.h +1
-1@@ -244,7 +244,7 @@ enum {* definitely preferable to use the flag rather than opencode endless * loop around allocator. * Allocating pages from the buddy with __GFP_NOFAIL and order > 1 is -* not supported. Please consider using kvmalloc() instead. +* discouraged. Please consider using kvmalloc() instead if possible. */ #define __GFP_IO ((__force gfp_t)___GFP_IO)#define __GFP_FS ((__force gfp_t)___GFP_FS)mm/page_alloc.c +1
-1@@ -4804,7 +4804,7 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order,if (unlikely (nofail)) {/* -* Also we don't support __GFP_NOFAIL without __GFP_DIRECT_RECLAIM, +* We don't support __GFP_NOFAIL without __GFP_DIRECT_RECLAIM, * otherwise, we may result in lockup. */ WARN_ON_ONCE (!can_direct_reclaim);
Quoted 6 lines · Wei Yang
Commit
ee040cbd6e48("mm/page_alloc: don't warn about large allocations with__GFP_NOFAIL") remove a warning on allocating large folio with__GFP_NOFAIL, which was placed there by commit903edea6c53f("mm: warn about illegal__GFP_NOFAILusage in a more appropriate location and manner").
Quoted 7 lines
While in that commit, it also documented this behavior which is out-dated now.
Adjust the document to align to current code, and adjust the comment while at it.
Signed-off-by Wei Yang <[email protected]>
LGTM so:
Quoted 39 lines
---
v2:
* s/is adjusted/was placed there/ in change log
* instead of removing the document, say "is discouraged"v1: https://lore.kernel.org/all/[email protected]/T/#u
--- include/linux/gfp_types.h | 2 +- mm/page_alloc.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)include/linux/gfp_types.h +1
-1@@ -244,7 +244,7 @@ enum {* definitely preferable to use the flag rather than opencode endless * loop around allocator. * Allocating pages from the buddy with __GFP_NOFAIL and order > 1 is -* not supported. Please consider using kvmalloc() instead. +* discouraged. Please consider using kvmalloc() instead if possible. */ #define __GFP_IO ((__force gfp_t)___GFP_IO)#define __GFP_FS ((__force gfp_t)___GFP_FS)mm/page_alloc.c +1
-2@@ -4804,7 +4804,7 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order,if (unlikely (nofail)) {/* -* Also we don't support __GFP_NOFAIL without __GFP_DIRECT_RECLAIM, +* We don't support __GFP_NOFAIL without __GFP_DIRECT_RECLAIM, * otherwise, we may result in lockup. */ WARN_ON_ONCE (!can_direct_reclaim); --
Quoted 2 lines
2.34.1
--
Cheers, Lorenzo
Quoted 19 lines · Wei Yang
Commit
ee040cbd6e48("mm/page_alloc: don't warn about large allocations with__GFP_NOFAIL") remove a warning on allocating large folio with__GFP_NOFAIL, which was placed there by commit903edea6c53f("mm: warn about illegal__GFP_NOFAILusage in a more appropriate location and manner").While in that commit, it also documented this behavior which is out-dated now.
Adjust the document to align to current code, and adjust the comment while at it.
Signed-off-by Wei Yang <[email protected]>---
v2:
* s/is adjusted/was placed there/ in change log
* instead of removing the document, say "is discouraged"
Quoted 6 lines
v1: https://lore.kernel.org/all/[email protected]/T/#u
--- include/linux/gfp_types.h | 2 +- mm/page_alloc.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
LGTM.
Signature · 2 lines
Best Regards, Yan, Zi