On Wed 24-07-24 20:55:43, Barry Song wrote:
> From: Barry Song <v-songbaohua@xxxxxxxx>
>
> 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@xxxxxxxx>
> ---
> 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
