[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20240509095030.t3gnhkuntj6t3w6p@oppo.com>
Date: Thu, 9 May 2024 17:50:30 +0800
From: Hailong Liu <hailong.liu@...o.com>
To: Barry Song <21cnbao@...il.com>
CC: Michal Hocko <mhocko@...e.com>, <akpm@...ux-foundation.org>,
<urezki@...il.com>, <hch@...radead.org>, <lstoakes@...il.com>,
<linux-mm@...ck.org>, <linux-kernel@...r.kernel.org>, <xiang@...nel.org>,
<chao@...nel.org>, Oven <liyangouwen1@...o.com>
Subject: Re: [RFC PATCH] mm/vmalloc: fix vmalloc which may return null if
called with __GFP_NOFAIL
On Thu, 09. May 20:57, Barry Song wrote:
>
> Upon further examination, it's not a bug, but we can still utilize 'nofail'.
> The current code is very hard to read about gfp and "nofail" :-)
>
> maybe:
>
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 6641be0ca80b..7c66fe16c2ad 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -3498,7 +3498,7 @@ vm_area_alloc_pages(gfp_t gfp, int nid,
> {
> unsigned int nr_allocated = 0;
> gfp_t alloc_gfp = gfp;
> - bool nofail = false;
> + bool nofail = !!(gfp & __GFP_NOFAIL);
> struct page *page;
> int i;
>
> @@ -3555,7 +3555,6 @@ vm_area_alloc_pages(gfp_t gfp, int nid,
> * and compaction etc.
> */
> alloc_gfp &= ~__GFP_NOFAIL;
> - nofail = true;
> }
Thanks for suggestion. I think that makes more clearly. Will
try it in next version.
--
Best Regards,
Hailong.
Powered by blists - more mailing lists