From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id F338526CE34 for ; Mon, 8 Dec 2025 06:41:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765176103; cv=none; b=I5TdmSWB5qfFbDnDe/iouknGcHm/03Hpxj0bOlsPfsFEEaK3LPaXWM5/xYcgunhVUdWet1IQFlzyCVbwo8CXaYDUHWqQoFbVYnPP7C5kw0+lgSEpqBX0aBZO1bUmT1KrbXi2Da+9wigD1cRFCnuqi4nIZJDQnN24YMOk79OsT54= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765176103; c=relaxed/simple; bh=YcWxq4ATehnzK1Iz6X/TAp8JstVinc43l7bKPRA6OSM=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=c/4uO8YMZATzJU8t7ZHKWlGhPIKHE8ITfDiXkEvE2fjdxGLJN1IxI63X+DmSLj+9ERfhZ9bb29Qrfw3EeHGqf2tbgv6VRYgFRQ8Ic0SOS4sFzwkXvpnsGXTsPKH3IWieoQ0r3DRUwpG/2TzAnfPPbs+ExkF51t51r/Rr4AnyWMY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id BBC01169C; Sun, 7 Dec 2025 22:41:32 -0800 (PST) Received: from [10.164.18.52] (unknown [10.164.18.52]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 886633F740; Sun, 7 Dec 2025 22:41:38 -0800 (PST) Message-ID: <96aa9bf7-1f1d-4870-90d2-84d3d6d4254c@arm.com> Date: Mon, 8 Dec 2025 12:11:35 +0530 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mm/vmalloc: clarify why vmap_range_noflush() might sleep To: Brendan Jackman , Andrew Morton , Uladzislau Rezki Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20251208-b4-vmalloc-might_alloc-v1-1-94a9bb8ecb08@google.com> Content-Language: en-US From: Anshuman Khandual In-Reply-To: <20251208-b4-vmalloc-might_alloc-v1-1-94a9bb8ecb08@google.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 08/12/25 10:49 AM, Brendan Jackman wrote: > The only reason vmap_range_noflush() can sleep is because of pagetable > allocations. This might_sleep() is accurate, but we have a more > precise way to express this particular case, so help readers out by > using that. > > Note that the actual GFP flags used to allocate here are arch-specific. > But as long as GFP_PGTABLE_KERNEL includes blockable flags, it should Currently GFP_PGTABLE_KERNEL does have a blocking flag via GFP_KERNEL. #define GFP_PGTABLE_KERNEL (GFP_KERNEL | __GFP_ZERO) #define GFP_KERNEL (__GFP_RECLAIM | __GFP_IO | __GFP_FS) #define __GFP_RECLAIM ((__force gfp_t)(___GFP_DIRECT_RECLAIM|___GFP_KSWAPD_RECLAIM)) > serve as a reasonable common-denominator here. Agreed. > > This also ensures there is an fs_reclaim_acquire() even no pagetables > are actually allocated, which could potentially do a better job at > catching filesystem bugs. Makes sense. > > --- > Signed-off-by: Brendan Jackman > --- > mm/vmalloc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > index a53c7462671bdd896f95712af71398ffbe22fb80..ff1876588b94ec69168324e93399dbd117a6959a 100644 > --- a/mm/vmalloc.c > +++ b/mm/vmalloc.c > @@ -305,7 +305,7 @@ static int vmap_range_noflush(unsigned long addr, unsigned long end, > int err; > pgtbl_mod_mask mask = 0; > > - might_sleep(); > + might_alloc(GFP_PGTABLE_KERNEL); This will invariably add a might_sleep() and hence preserves the existing behaviour besides adding fs_reclaim_acquire() which is an improvement. > BUG_ON(addr >= end); > > start = addr; > > --- > base-commit: ecc46e02e0abe025a6e840cba2d647f23fd1d721 > change-id: 20251208-b4-vmalloc-might_alloc-754a791e4e10 > > Best regards, Please add in mm/vmalloc.c - otherwise it does not get built as GFP_PGTABLE_KERNEL is not available. But otherwise LGTM. After fixing the build. Reviewed-by: Anshuman Khandual