From: Wei Yang <richard.weiyang@gmail.com>
To: akpm@linux-foundation.org, david@kernel.org, ljs@kernel.org,
liam@infradead.org, vbabka@kernel.org, rppt@kernel.org,
surenb@google.com, mhocko@suse.com, brendan.jackman@linux.dev,
hannes@cmpxchg.org, ziy@nvidia.com
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Wei Yang <richard.weiyang@gmail.com>,
Baokun Li <libaokun1@huawei.com>
Subject: [PATCH] mm: remove out-dated document of __GFP_NOFAIL
Date: Thu, 27 Aug 2026 03:05:48 +0000 [thread overview]
Message-ID: <20260827030548.16631-1-richard.weiyang@gmail.com> (raw)
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 <richard.weiyang@gmail.com>
Cc: Baokun Li <libaokun1@huawei.com>
---
include/linux/gfp_types.h | 2 --
mm/page_alloc.c | 2 +-
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/include/linux/gfp_types.h b/include/linux/gfp_types.h
index 190191411009..24fde8eb73df 100644
--- a/include/linux/gfp_types.h
+++ b/include/linux/gfp_types.h
@@ -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)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index ab385bc252cc..146f7e0a9462 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -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);
--
2.34.1
next reply other threads:[~2026-08-27 3:06 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-27 3:05 Wei Yang [this message]
2026-08-27 7:35 ` [PATCH] mm: remove out-dated document of __GFP_NOFAIL Vlastimil Babka (SUSE)
2026-08-27 7:49 ` Wei Yang
2026-08-27 8:03 ` Vlastimil Babka (SUSE)
2026-08-27 8:09 ` Wei Yang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260827030548.16631-1-richard.weiyang@gmail.com \
--to=richard.weiyang@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=brendan.jackman@linux.dev \
--cc=david@kernel.org \
--cc=hannes@cmpxchg.org \
--cc=liam@infradead.org \
--cc=libaokun1@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mhocko@suse.com \
--cc=rppt@kernel.org \
--cc=surenb@google.com \
--cc=vbabka@kernel.org \
--cc=ziy@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox