All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@suse.com>
To: Barry Song <21cnbao@gmail.com>
Cc: akpm@linux-foundation.org, linux-mm@kvack.org,
	42.hyeyoo@gmail.com, cl@linux.com, hch@infradead.org,
	iamjoonsoo.kim@lge.com, lstoakes@gmail.com, penberg@kernel.org,
	rientjes@google.com, roman.gushchin@linux.dev, urezki@gmail.com,
	v-songbaohua@oppo.com, vbabka@suse.cz,
	virtualization@lists.linux.dev, hailong.liu@oppo.com,
	torvalds@linux-foundation.org
Subject: Re: [PATCH 2/5] mm: Document __GFP_NOFAIL must be blockable
Date: Wed, 24 Jul 2024 13:58:09 +0200	[thread overview]
Message-ID: <ZqDsUZDLZOXTPwuA@tiehlicka> (raw)
In-Reply-To: <20240724085544.299090-3-21cnbao@gmail.com>

On Wed 24-07-24 20:55:41, Barry Song wrote:
> From: Barry Song <v-songbaohua@oppo.com>
> 
> Non-blocking allocation with __GFP_NOFAIL is not supported and may
> still result in NULL pointers (if we don't return NULL, we result
> in busy-loop within non-sleepable contexts):
> 
> static inline struct page *
> __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order,
> 						struct alloc_context *ac)
> {
> 	...
> 	/*
> 	 * Make sure that __GFP_NOFAIL request doesn't leak out and make sure
> 	 * we always retry
> 	 */
> 	if (gfp_mask & __GFP_NOFAIL) {
> 		/*
> 		 * All existing users of the __GFP_NOFAIL are blockable, so warn
> 		 * of any new users that actually require GFP_NOWAIT
> 		 */
> 		if (WARN_ON_ONCE_GFP(!can_direct_reclaim, gfp_mask))
> 			goto fail;
> 		...
> 	}
> 	...
> fail:
> 	warn_alloc(gfp_mask, ac->nodemask,
> 			"page allocation failure: order:%u", order);
> got_pg:
> 	return page;
> }
> 
> Highlight this in the documentation of __GFP_NOFAIL so that non-mm
> subsystems can reject any illegal usage of __GFP_NOFAIL with
> GFP_ATOMIC, GFP_NOWAIT, etc.
> 
> Signed-off-by: Barry Song <v-songbaohua@oppo.com>

Acked-by: Michal Hocko <mhocko@suse.com>

> ---
>  include/linux/gfp_types.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/include/linux/gfp_types.h b/include/linux/gfp_types.h
> index 313be4ad79fd..0dad2c7914be 100644
> --- a/include/linux/gfp_types.h
> +++ b/include/linux/gfp_types.h
> @@ -246,6 +246,8 @@ enum {
>   * cannot handle allocation failures. The allocation could block
>   * indefinitely but will never return with failure. Testing for
>   * failure is pointless.
> + * It _must_ be blockable and used together with __GFP_DIRECT_RECLAIM.
> + * It should _never_ be used in non-sleepable contexts.
>   * New users should be evaluated carefully (and the flag should be
>   * used only when there is no reasonable failure policy) but it is
>   * definitely preferable to use the flag rather than opencode endless
> -- 
> 2.34.1

Do you think the following addendum should be folded in just for
completness?

diff --git a/include/linux/gfp_types.h b/include/linux/gfp_types.h
index 313be4ad79fd..d024cfd1af8e 100644
--- a/include/linux/gfp_types.h
+++ b/include/linux/gfp_types.h
@@ -215,7 +215,8 @@ enum {
  * the caller still has to check for failures) while costly requests try to be
  * not disruptive and back off even without invoking the OOM killer.
  * The following three modifiers might be used to override some of these
- * implicit rules.
+ * implicit rules. Please note that all of them must be used along with
+ * %__GFP_DIRECT_RECLAIM flag.
  *
  * %__GFP_NORETRY: The VM implementation will try only very lightweight
  * memory direct reclaim to get some memory under memory pressure (thus

-- 
Michal Hocko
SUSE Labs

  reply	other threads:[~2024-07-24 11:58 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-24  8:55 [PATCH 0/5] mm: clarify nofail memory allocation Barry Song
2024-07-24  8:55 ` [PATCH RFC 1/5] vpda: try to fix the potential crash due to misusing __GFP_NOFAIL Barry Song
2024-07-24 12:26   ` Michal Hocko
2024-07-24 22:50     ` Barry Song
2024-07-25  6:08       ` Michal Hocko
2024-07-25  7:00         ` Barry Song
2024-07-29  3:42           ` Jason Wang
2024-07-29  6:05             ` Barry Song
2024-07-30  2:48               ` Jason Wang
2024-07-30  3:08                 ` Barry Song
2024-07-30  3:13                   ` Jason Wang
2024-07-24  8:55 ` [PATCH 2/5] mm: Document __GFP_NOFAIL must be blockable Barry Song
2024-07-24 11:58   ` Michal Hocko [this message]
2024-08-03 23:09   ` Davidlohr Bueso
2024-07-24  8:55 ` [PATCH 3/5] mm: BUG_ON to avoid NULL deference while __GFP_NOFAIL fails Barry Song
2024-07-24 10:03   ` Vlastimil Babka
2024-07-24 10:11     ` Barry Song
2024-07-24 12:10   ` Michal Hocko
2024-07-24  8:55 ` [PATCH 4/5] mm: Introduce GFP_NOFAIL with the inclusion of __GFP_RECLAIM Barry Song
2024-07-24 12:12   ` Michal Hocko
2024-07-24  8:55 ` [PATCH RFC 5/5] non-mm: discourage the usage of __GFP_NOFAIL and encourage GFP_NOFAIL Barry Song
2024-07-24  9:53   ` Vlastimil Babka
2024-07-24  9:58     ` Barry Song
2024-07-24 13:14       ` Christoph Hellwig
2024-07-24 12:25     ` Michal Hocko
2024-07-24 13:13     ` Christoph Hellwig
2024-07-24 13:21       ` Michal Hocko
2024-07-24 13:23         ` Christoph Hellwig
2024-07-24 13:31           ` Michal Hocko
2024-07-24 13:33             ` Vlastimil Babka
2024-07-24 13:38               ` Christoph Hellwig
2024-07-24 13:47                 ` Michal Hocko
2024-07-24 13:55                   ` Christoph Hellwig
2024-07-24 14:39                     ` Vlastimil Babka
2024-07-24 14:41                       ` Christoph Hellwig
2024-07-25  1:47                         ` Barry Song
2024-07-29  9:56                           ` Barry Song
2024-07-29 10:03                             ` Vlastimil Babka
2024-07-29 10:16                               ` Barry Song
2024-07-24 12:17   ` Michal Hocko
2024-07-25  1:38     ` Barry Song
2024-07-25  6:16       ` Michal Hocko
2024-07-26 21:08         ` Davidlohr Bueso
2024-07-29 11:50           ` Michal Hocko
2024-08-03 22:15             ` Davidlohr Bueso
2024-08-05  7:49               ` Michal Hocko
2024-07-25  1:17   ` kernel test robot
2024-07-25 14:20   ` Dan Carpenter

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=ZqDsUZDLZOXTPwuA@tiehlicka \
    --to=mhocko@suse.com \
    --cc=21cnbao@gmail.com \
    --cc=42.hyeyoo@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux.com \
    --cc=hailong.liu@oppo.com \
    --cc=hch@infradead.org \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=linux-mm@kvack.org \
    --cc=lstoakes@gmail.com \
    --cc=penberg@kernel.org \
    --cc=rientjes@google.com \
    --cc=roman.gushchin@linux.dev \
    --cc=torvalds@linux-foundation.org \
    --cc=urezki@gmail.com \
    --cc=v-songbaohua@oppo.com \
    --cc=vbabka@suse.cz \
    --cc=virtualization@lists.linux.dev \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.