From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id ECC092848AA for ; Mon, 13 Jul 2026 16:42:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783960947; cv=none; b=Y+wvOhaiptZINxIbT2YOKENcAfDoFB6vFexRUoBw59nsBz2emtgMNlq6a1E1zaPR5CxdVaBccLAB8zJAPoDXFFqLBjKf7WUHqnN395qqfeLEtLkINIc+XfzCYUiDAzo4Q2lgi0N2LPkFbvpvj88+BnINrQPEb3Ua7oX1xHtDg+c= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783960947; c=relaxed/simple; bh=0x4QPJy3oGRMxfHWoYqSLp4a5w7gPSX6tWw8LsKJyyI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=aLUENkmHbhqD5TgxfcR5pwRnB55L7/VFQGSA1edLZd25hYkPFUl4SYALlHUjXR8xQu+WFxOHMmhSgfaCbXSirwyji9X9PeEk1ymx13aIc+JSbtOyAarGvVCMVmVdifDklvZ54LbnA/fybp296VThNTK76D0NgW3sVushRo8mejI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=YMD95T5g; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="YMD95T5g" Received: by smtp.kernel.org (Postfix) with ESMTPSA id F2E261F00A3A; Mon, 13 Jul 2026 16:42:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783960945; bh=Zltyqt7dF1hkJN/jP/CdnhprTdfvpBe1oag9qSSox24=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=YMD95T5gB5V6T1KmPKUt3jBxes75nLN+JrX7ufd6wzFcjrcdf4OPFO5O/6KEGbI4p /qPsJdKgM1VcjGX+E9RJOqAdM796/JvnoQaOR0QS92oa5R1put/ZxPUddbroI2Tu71 FefurKURKfoiisCy/CjS7hvxUrfgD1Ex8u47gMffmBu9NPWCSru1kAE1rx7Y29oejY 7i1zDqIEnOgFDcMGP2JEkipfRSoxeoDToKGDEsej2BP1w2RYFvievCeyzKg1L1xlH/ YKrYIjUxFoY2yWG5K3uqnUsZ7F3Xt7FFGhZzEg5MwswwfwagH1A1r0Bqd8ZvZEmx63 Lmwi+0z29/2Zw== Received: from phl-compute-07.internal (phl-compute-07.internal [10.202.2.47]) by mailfauth.phl.internal (Postfix) with ESMTP id 2C724F40209; Mon, 13 Jul 2026 12:42:24 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-07.internal (MEProxy); Mon, 13 Jul 2026 12:42:24 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTGMoWnWRGMKpgIRcZga9S7P7sHAGK5d+gFuMURcEOT0aJUrqozEaYj6fAMVLY196L c7Q9Qx95Y6WcY327qRelJqkKmKiY8PyHcdZc3JZu/hVxbAUCmEOUcUUvGZPJlzK+Zg1A7p E1M4Hr0gckN5dJRqg90LQ0EHm2k1fI/i+fUhPF+S0gisFoPy96WSVpdPglvA43z/98UfZS 77zo20OTGrNknxecuDjYSkHGwSxjzQ1LYlvgazPzK8oFp3YKDb/rYy0YfHXnH6tiE3ZJF7 ZokTq2XxIK+Yzvex9+lS2uKqt+BJb+586vgE/3bYp3UeKEBWyikgLa9l9cHHjIxzYEIHil oF2jNkQA3L0opoOSBPQ21b1KwnAtX+7mm1hI1VkIvCQ4Sd8xTjNlbp2bhYvHJ2okcMR4ns hsRCs5wvczPDK1sHUQYigsqKB7ZtUPERQqVE+pr7t0diJqU2CJ0D6rKy0JLWAbPnh0PP+w GMO82NWmJpzPCDTYl7tKUndgaEXCJlprGOkG6oO+jiyNiJ6ompZ9Gl/0s/kkHRKHMwro8s R9WYSyj47gkweDae0dm64/jnpgoYlfQRkSg8eWsf6jTGBGtei9aL7PRaOPj+mFaLXnfhGc FUKxgsObsfGFTX1wCE5bSoek7+u19U/q8fwZmEcgbsplA5BpMngGDPZ0RlYA X-ME-Proxy: Feedback-ID: i10464835:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 13 Jul 2026 12:42:22 -0400 (EDT) Date: Mon, 13 Jul 2026 17:42:21 +0100 From: Kiryl Shutsemau To: Lorenzo Stoakes Cc: Andrew Morton , Suren Baghdasaryan , "Liam R. Howlett" , Vlastimil Babka , Shakeel Butt , David Hildenbrand , Mike Rapoport , Michal Hocko , Uladzislau Rezki , Toshi Kani , Dave Hansen , Andy Lutomirski , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , Borislav Petkov , x86@kernel.org, "H. Peter Anvin" , Catalin Marinas , Will Deacon , Dev Jain , Ryan Roberts , David Carlier , linux-mm@kvack.org, linux-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, stable@vger.kernel.org, syzbot+fd95a72470f5a44e464c@syzkaller.appspotmail.com Subject: Re: [PATCH mm-hotfixes v2 1/4] mm/vmalloc: acquire init_mm lock on huge vmap to avoid ptdump UAF Message-ID: References: <20260712-series-vmap-race-fix-v2-0-ad134cc3a12a@kernel.org> <20260712-series-vmap-race-fix-v2-1-ad134cc3a12a@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260712-series-vmap-race-fix-v2-1-ad134cc3a12a@kernel.org> On Sun, Jul 12, 2026 at 11:42:24AM +0100, Lorenzo Stoakes wrote: > Currently there is a nasty race between ptdump and vmap when attempting to > map a huge P4D, PMD or PUD entry. <... skip 145 lines of commit message :P > The code looks good to me, but I think the commit message needs some love. It is long, and the pieces of the story are scattered: the race itself only shows up around the middle, after several paragraphs of ptdump background (including the arm32 and EFI notes that the text itself says are not relevant to the bug), and the one genuinely subtle part -- why the read lock is sufficient -- is not spelled out at all. Something along these lines would be much easier to follow: 1. The race, up front. Diagram, if we you feel like it; 2. The fix, and why the read lock is enough; 3. Why a trylock; 4. The arm64 wrinkle and the temporary ifdeffery patch 4 removes; 5. Secondary changes (guard class, walk_page_range_debug() assert); 6. History, if you feel like it. Point 2 is the one I care about most -- the same reasoning would also help in the comment in vmap_try_huge_pmd(), where "Therefore, acquire the mmap read lock" is doing a lot of unexplained work. -- Kiryl Shutsemau / Kirill A. Shutemov