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 3D14832F74B for ; Tue, 16 Dec 2025 04:16:47 +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=1765858633; cv=none; b=cIwb4nFTZuTg5YqdngL7hu9nA9NAQL6YPofWABZas3ky9gy/zcgfI78auyXc+ERwIwHK8xAyPByHZ6StyqDDPXiyJ4tQXzNWWgnbDjd+dpEw6v3EaATPPG5JrI+poPObgBIQ0823q9bwLHOXUURizsfwGZLZMW41WNuGJOkBMFM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765858633; c=relaxed/simple; bh=ef2o0bx3SmhNdLK8IXLZfLa9adDvXqFp8ptmz6ZuG4E=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=GCm4bRcBu8GhjvRv0zn+NyATTwChqmn0JGSOxedFYb9g3BZmjkKpWiD2DBNxPsTruce0qRy4O+mNtgeuF+FMVPORD5RSraeKz2Al5JTXBOWk70nbhqDbyCZ8C8V7aRI3VkPD/22QCVp4d4jopH/vTx376PhA1G4ho4tUWmWagfs= 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 EF353FEC; Mon, 15 Dec 2025 20:16:34 -0800 (PST) Received: from [10.163.80.100] (unknown [10.163.80.100]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 739BC3F762; Mon, 15 Dec 2025 20:16:40 -0800 (PST) Message-ID: <66068425-c9b2-475e-81ad-98f410d33b45@arm.com> Date: Tue, 16 Dec 2025 09:46:37 +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 v3] 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: <20251215-b4-vmalloc-might_alloc-v3-1-92dd8e406868@google.com> Content-Language: en-US From: Anshuman Khandual In-Reply-To: <20251215-b4-vmalloc-might_alloc-v3-1-92dd8e406868@google.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 15/12/25 4:10 PM, Brendan Jackman wrote: > The only reason vmap_range_noflush() can sleep is because of pagetable > allocations. > > The actual allocation mechanism is arch-specific so might_alloc() > doesn't work here (what GFP flags would be used?). Hence, just add a > comment. > > Also note that this might do a TLB shootdown. This is not actually > sleeping but it requires IRQs on for x86, and might_sleep() incidentally > serves to detect violations of that too. > > Signed-off-by: Brendan Jackman Reviewed-by: Anshuman Khandual > --- > Applies to mm-new. > > Changes in v3: > - Added note about TLB shootdowns and x86. > - Since the comment no longer fit on one line anyway, also be a bit more > verbose in general. > - Link to v2: https://lore.kernel.org/r/20251209-b4-vmalloc-might_alloc-v2-1-2462ba26ead1@google.com > > Changes in v2: > - Switched from might_alloc() to keeping might_sleep() + comment > - Link to v1: https://lore.kernel.org/r/20251208-b4-vmalloc-might_alloc-v1-1-94a9bb8ecb08@google.com > --- > mm/vmalloc.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > index 41dd01e8430c548167d6123f6ec66bf798f20eec..be4e5f2566a4490d45de29568df538b7c8515b01 100644 > --- a/mm/vmalloc.c > +++ b/mm/vmalloc.c > @@ -305,6 +305,11 @@ static int vmap_range_noflush(unsigned long addr, unsigned long end, > int err; > pgtbl_mod_mask mask = 0; > > + /* > + * Might allocate pagetables (for most archs a more precise annotation > + * would be might_alloc(GFP_PGTABLE_KERNEL)). Also might shootdown TLB > + * (requires IRQs enabled on x86). > + */ > might_sleep(); > BUG_ON(addr >= end); > > > --- > base-commit: d0a24447990a9d8212bfb3a692d59efa74ce9f86 > change-id: 20251208-b4-vmalloc-might_alloc-754a791e4e10 > > Best regards,