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 4/5] mm: Introduce GFP_NOFAIL with the inclusion of __GFP_RECLAIM
Date: Wed, 24 Jul 2024 14:12:28 +0200 [thread overview]
Message-ID: <ZqDvrN73W6F89O6K@tiehlicka> (raw)
In-Reply-To: <20240724085544.299090-5-21cnbao@gmail.com>
On Wed 24-07-24 20:55:43, Barry Song wrote:
> From: Barry Song <v-songbaohua@oppo.com>
>
> Introducing GFP_NOFAIL and gradually increasing enforcement to prevent
> direct use of __GFP_NOFAIL which might be misused within non-sleepable
> contexts with GFP_ATOMIC and GFP_NOWAIT.
I do not think this makes sense without removing __GFP_NOFAIL and
changing existing users because a new flag will very likely not be used
and therefore it will not achieve the ultimate goal to remove a
potential abuse.
> Signed-off-by: Barry Song <v-songbaohua@oppo.com>
> ---
> include/linux/gfp_types.h | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/include/linux/gfp_types.h b/include/linux/gfp_types.h
> index 0dad2c7914be..1666db74f25c 100644
> --- a/include/linux/gfp_types.h
> +++ b/include/linux/gfp_types.h
> @@ -339,6 +339,10 @@ enum {
> * recurse into the FS layer with a short explanation why. All allocation
> * requests will inherit GFP_NOFS implicitly.
> *
> + * %GFP_NOFAIL employs direct memory reclaim and continuously retries until
> + * successful memory allocation. It should never be used in contexts where
> + * sleeping is not allowed.
> + *
> * %GFP_USER is for userspace allocations that also need to be directly
> * accessibly by the kernel or hardware. It is typically used by hardware
> * for buffers that are mapped to userspace (e.g. graphics) that hardware
> @@ -378,6 +382,7 @@ enum {
> #define GFP_NOWAIT (__GFP_KSWAPD_RECLAIM | __GFP_NOWARN)
> #define GFP_NOIO (__GFP_RECLAIM)
> #define GFP_NOFS (__GFP_RECLAIM | __GFP_IO)
> +#define GFP_NOFAIL (__GFP_RECLAIM | __GFP_NOFAIL)
> #define GFP_USER (__GFP_RECLAIM | __GFP_IO | __GFP_FS | __GFP_HARDWALL)
> #define GFP_DMA __GFP_DMA
> #define GFP_DMA32 __GFP_DMA32
> --
> 2.34.1
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2024-07-24 12:12 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
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 [this message]
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=ZqDvrN73W6F89O6K@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.