From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 591AE368D6F for ; Wed, 13 May 2026 17:38:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778693888; cv=none; b=GQAsqor+G79JkwnmhfEWfLQDA/wUb9mLdLRKXcVbTDzjfX5jEzC36gnulSquSng6qtZLgyf2GVyZpksIkGAP/hANAhk/amtXhQDfOqJ4IEc33nC9ESRF+PPpglF2wLocMRgPhMCnsFAu1oPwB3sisVvlYvOxIG83pe6cwKVxDgA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778693888; c=relaxed/simple; bh=rsip1DDwsdG360XbgIRx/1LGp5r5fvNgF7AYUVqhpUY=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=rNpsorj4p9Bct+iX/0fRqXmIpaoPGE7Uww3KOMM0/mPwnXhrQO+WeSbe3bpuGZP2y7/bYUMFkXZAmqbspDm4Wr5c7K2WKYVpb1ZZAudnFGLVfLdepz36ho9bstc9kU1y30V/pt0Un+Ra7M2y4UorxZ4/FQ4GE/03TZDATk4ivdY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=KXclouBc; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="KXclouBc" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D582DC2BCC6; Wed, 13 May 2026 17:38:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1778693887; bh=rsip1DDwsdG360XbgIRx/1LGp5r5fvNgF7AYUVqhpUY=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=KXclouBcy6lsmCAD7LiLS3b7oxlVP+aM73apIEFrcE5S3iKo7JnqCjMDBr2TmyTuB 0XRaHz72RuzZ2Etk8SqeJ+4U67npQxvclZfuuO+jXB9xWGDXnh/VUGwlUqcBvtRqN2 vOlGLJAPX5B7iTHY8H2crKbOXve+/xsU2nA2HESu+l4/e0VWAJ+wmMTxhJ0EH9MwK0 qUgxYGhpos0o1p10guBMecfQz/WVzIKmNmdp5MFcKu14TQzz9/RSXWD3KPQQKrhQTU dNIyuM4XIejkVYeWJz6ARV9P204yAzfrFoDokAms3OTMgF9l8BVi6AS++03BPqIPC6 W9GUIiNAmDgtA== Message-ID: Date: Wed, 13 May 2026 19:38:01 +0200 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 v2 00/22] mm: Add __GFP_UNMAPPED Content-Language: en-US To: Gregory Price , Brendan Jackman Cc: Borislav Petkov , Dave Hansen , Peter Zijlstra , Andrew Morton , David Hildenbrand , Wei Xu , Johannes Weiner , Zi Yan , Lorenzo Stoakes , linux-mm@kvack.org, linux-kernel@vger.kernel.org, x86@kernel.org, rppt@kernel.org, Sumit Garg , derkling@google.com, reijiw@google.com, Will Deacon , rientjes@google.com, "Kalyazin, Nikita" , patrick.roy@linux.dev, "Itazuri, Takahiro" , Andy Lutomirski , David Kaplan , Thomas Gleixner , Yosry Ahmed References: <20260320-page_alloc-unmapped-v2-0-28bf1bd54f41@google.com> From: "Vlastimil Babka (SUSE)" In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 5/13/26 19:28, Gregory Price wrote: > > Hm. I'm not quite wrapping my head around the TLB issue fully. > > If there's no kernel direct mapping, and there's no userland mapping, > the stale TLB entry comes from... the page formerly being present in the > page tables and a stale TLB entry lying about after the page is freed? It's the direct mapping, we assume it's always there and unchanged, and only kernel can access the contents through it. So nobody flushes it when freeing any pages. Userspace processes can't exploit anything stale there, in absence of kernel's UAF bugs (or e.g. Meltdown like cpu bugs). > If that's the case, that sounds more like someone isn't flushing the TLB > entry correctly when the page is freed or unmapped (for a transient > mermap situation), rather than an issue to be handled by the allocator. > > I think I just need to spend a little more time understanding the TLB > issue. >