mm: remove out-dated document of __GFP_NOFAIL

PATCH Superseded Wei Yang 2 participants 5 messages Aug 27

Subsystems (3)

Memory management MM core Page allocator

lore

Share & tools

lore

Wei Yang

author

2026-08-27 03:05 UTC #0 lore raw

PATCH 1/1 mm: remove 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 is adjusted 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.

Signed-off-by Wei Yang <[email protected]>

Cc Baokun Li <[email protected]>

---
 include/linux/gfp_types.h | 2 --
 mm/page_alloc.c           | 2 +-
 2 files changed, 1 insertion(+), 3 deletions(-)

include/linux/gfp_types.h +0 -2

index 190191411009..24fde8eb73df 100644
@@ -243,8 +243,6 @@ enum {
  * used only when there is no reasonable failure policy) but it is
  * 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.
  */
 #define __GFP_IO	((__force gfp_t)___GFP_IO)
 #define __GFP_FS	((__force gfp_t)___GFP_FS)

mm/page_alloc.c +1 -1

index ab385bc252cc..146f7e0a9462 100644
@@ -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

Vlastimil Babka (SUSE)

maintainer

2026-08-27 07:35 UTC #1 lore raw

Quoted 4 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 is adjusted by commit 903edea6c53f ("mm: warn about illegal __GFP_NOFAIL usage in a more appropriate location and manner").

"which is adjusted by commit" sounds as 903edea6c53f came later than ee040cbd6e48, but it's the opposite. Maybe say "which was placed there"?

Quoted 18 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]>
Cc Baokun Li <[email protected]>
---
 include/linux/gfp_types.h | 2 --
 mm/page_alloc.c           | 2 +-
 2 files changed, 1 insertion(+), 3 deletions(-)
include/linux/gfp_types.h +0 -0
index 190191411009..24fde8eb73df 100644

include/linux/gfp_types.h enum { · line 247

Quoted 5 lines

include/linux/gfp_types.h +0 -2

@@ -243,8 +243,6 @@ enum {
  * used only when there is no reasonable failure policy) but it is
  * 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.

I'm not sure if we want to simply remove the lines, or rather say it's discouraged (instead of not supported) and still suggest kvmalloc() if possible.

Quoted 16 lines

include/linux/gfp_types.h +0 -0

  */
 #define __GFP_IO	((__force gfp_t)___GFP_IO)
 #define __GFP_FS	((__force gfp_t)___GFP_FS)

mm/page_alloc.c +1 -1

index ab385bc252cc..146f7e0a9462 100644
@@ -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);

Wei Yang

author

2026-08-27 07:49 UTC #2 lore raw

Quoted 9 lines · Vlastimil Babka (SUSE)

Quoted 4 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 is adjusted by commit 903edea6c53f ("mm: warn about illegal __GFP_NOFAIL usage in a more appropriate location and manner").
"which is adjusted by commit" sounds as 903edea6c53f came later than ee040cbd6e48, but it's the opposite. Maybe say "which was placed there"?

Got it.

Quoted 13 lines

Quoted 13 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]>
Cc Baokun Li <[email protected]>
---
 include/linux/gfp_types.h | 2 --
 mm/page_alloc.c           | 2 +-
 2 files changed, 1 insertion(+), 3 deletions(-)

Quoted 15 lines

include/linux/gfp_types.h enum { · line 247
Quoted 10 lines
include/linux/gfp_types.h +0 -2
index 190191411009..24fde8eb73df 100644
@@ -243,8 +243,6 @@ enum {
  * used only when there is no reasonable failure policy) but it is
  * 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.
I'm not sure if we want to simply remove the lines, or rather say it's discouraged (instead of not supported) and still suggest kvmalloc() if possible.

Reasonable.

As mentioned in [1], kvmalloc() maybe not suitable for some cases, I would suggest below change.

* Allocating pages from the buddy with __GFP_NOFAIL and order > 1 is
* discouraged. Please consider using kvmalloc() instead if possible.

Or, you prefer only s/supported/discouraged/ ?

[1]: https://lore.kernel.org/all/[email protected]

Quoted 16 lines

include/linux/gfp_types.h +0 -0

  */
 #define __GFP_IO	((__force gfp_t)___GFP_IO)
 #define __GFP_FS	((__force gfp_t)___GFP_FS)

mm/page_alloc.c +1 -1

index ab385bc252cc..146f7e0a9462 100644
@@ -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 · 2 lines

Wei Yang
Help you, Help me

Vlastimil Babka (SUSE)

maintainer

2026-08-27 08:03 UTC #3 lore raw

Quoted 42 lines · Wei Yang

Quoted 9 lines · Vlastimil Babka (SUSE)
Quoted 4 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 is adjusted by commit 903edea6c53f ("mm: warn about illegal __GFP_NOFAIL usage in a more appropriate location and manner").
"which is adjusted by commit" sounds as 903edea6c53f came later than ee040cbd6e48, but it's the opposite. Maybe say "which was placed there"?
Got it.
Quoted 13 lines
Quoted 13 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]>
Cc Baokun Li <[email protected]>
---
 include/linux/gfp_types.h | 2 --
 mm/page_alloc.c           | 2 +-
 2 files changed, 1 insertion(+), 3 deletions(-)
Quoted 15 lines
include/linux/gfp_types.h enum { · line 247
Quoted 10 lines
include/linux/gfp_types.h +0 -2
index 190191411009..24fde8eb73df 100644
@@ -243,8 +243,6 @@ enum {
  * used only when there is no reasonable failure policy) but it is
  * 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.
I'm not sure if we want to simply remove the lines, or rather say it's discouraged (instead of not supported) and still suggest kvmalloc() if possible.

Quoted 7 lines

Reasonable.
As mentioned in [1], kvmalloc() maybe not suitable for some cases, I would suggest below change.
* Allocating pages from the buddy with __GFP_NOFAIL and order > 1 is
* discouraged. Please consider using kvmalloc() instead if possible.

Yeah that's great! Thanks.

Quoted 21 lines

Or, you prefer only s/supported/discouraged/ ?

[1]: https://lore.kernel.org/all/[email protected]

Quoted 16 lines

include/linux/gfp_types.h +0 -0

  */
 #define __GFP_IO	((__force gfp_t)___GFP_IO)
 #define __GFP_FS	((__force gfp_t)___GFP_FS)

mm/page_alloc.c +1 -1

index ab385bc252cc..146f7e0a9462 100644
@@ -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);

Wei Yang

author

2026-08-27 08:09 UTC #4 lore raw

Quoted 45 lines · Vlastimil Babka (SUSE)

Quoted 44 lines · Wei Yang
Quoted 9 lines · Vlastimil Babka (SUSE)
Quoted 4 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 is adjusted by commit 903edea6c53f ("mm: warn about illegal __GFP_NOFAIL usage in a more appropriate location and manner").
"which is adjusted by commit" sounds as 903edea6c53f came later than ee040cbd6e48, but it's the opposite. Maybe say "which was placed there"?
Got it.
Quoted 13 lines
Quoted 13 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]>
Cc Baokun Li <[email protected]>
---
 include/linux/gfp_types.h | 2 --
 mm/page_alloc.c           | 2 +-
 2 files changed, 1 insertion(+), 3 deletions(-)
Quoted 15 lines
include/linux/gfp_types.h enum { · line 247
Quoted 10 lines
include/linux/gfp_types.h +0 -2
index 190191411009..24fde8eb73df 100644
@@ -243,8 +243,6 @@ enum {
  * used only when there is no reasonable failure policy) but it is
  * 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.
I'm not sure if we want to simply remove the lines, or rather say it's discouraged (instead of not supported) and still suggest kvmalloc() if possible.
Reasonable.

Quoted 8 lines

Quoted 5 lines
As mentioned in [1], kvmalloc() maybe not suitable for some cases, I would suggest below change.
* Allocating pages from the buddy with __GFP_NOFAIL and order > 1 is
* discouraged. Please consider using kvmalloc() instead if possible.
Yeah that's great! Thanks.

Thanks, I will wait a while for other comment before sending v2.

Quoted 21 lines

Or, you prefer only s/supported/discouraged/ ?

[1]: https://lore.kernel.org/all/[email protected]

Quoted 16 lines

include/linux/gfp_types.h +0 -0

  */
 #define __GFP_IO	((__force gfp_t)___GFP_IO)
 #define __GFP_FS	((__force gfp_t)___GFP_FS)

mm/page_alloc.c +1 -1

index ab385bc252cc..146f7e0a9462 100644
@@ -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 · 2 lines

Wei Yang
Help you, Help me