Received-SPF: pass (google.com: domain of linux-kernel+bounces-174373-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Received-SPF: Pass (protection.outlook.com: domain of oppo.com designates
 58.252.5.68 as permitted sender) receiver=protection.outlook.com;
 client-ip=58.252.5.68; helo=mail.oppo.com; pr=C
Date: Thu, 9 May 2024 17:50:30 +0800
From: Hailong Liu <hailong.liu@oppo.com>
To: Barry Song <21cnbao@gmail.com>
CC: Michal Hocko <mhocko@suse.com>, <akpm@linux-foundation.org>,
	<urezki@gmail.com>, <hch@infradead.org>, <lstoakes@gmail.com>,
	<linux-mm@kvack.org>, <linux-kernel@vger.kernel.org>, <xiang@kernel.org>,
	<chao@kernel.org>, Oven <liyangouwen1@oppo.com>
Subject: Re: [RFC PATCH] mm/vmalloc: fix vmalloc which may return null if
 called with __GFP_NOFAIL
Message-ID: <20240509095030.t3gnhkuntj6t3w6p@oppo.com>
References: <20240508125808.28882-1-hailong.liu@oppo.com>
 <Zjx_6F3Fti_EBD_e@tiehlicka>
 <20240509080636.bauxbgpqdluzpein@oppo.com>
 <CAGsJ_4wLF2+O2ydr8EvPqgrsOPsWStUxpzRvi3rJpktU_FSP1w@mail.gmail.com>
 <CAGsJ_4xqg7+xwsbXpU1yp_HkTBcpJwRN-ErEwzOZx915hgsyrQ@mail.gmail.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAGsJ_4xqg7+xwsbXpU1yp_HkTBcpJwRN-ErEwzOZx915hgsyrQ@mail.gmail.com>
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 May 2024 09:50:38.8462
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 9e7e2c8d-e4cd-440c-23dd-08dc700d7b95
X-MS-Exchange-CrossTenant-Id: f1905eb1-c353-41c5-9516-62b4a54b5ee6
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f1905eb1-c353-41c5-9516-62b4a54b5ee6;Ip=[58.252.5.68];Helo=[mail.oppo.com]
X-MS-Exchange-CrossTenant-AuthSource:
	HK3PEPF0000021D.apcprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SEYPR02MB5559

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.