From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f175.google.com (mail-qt1-f175.google.com [209.85.160.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9CC9F48B38F for ; Wed, 13 May 2026 17:59:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.175 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778695151; cv=none; b=cApAMoXxGKP0TDt4TnsRQqcpjfg0Wk62KNqrAWcarRgtlOBKMNZBmjfbjBKdYGVQBGwIuOXBHaVWksa7AXy1GKHBuFaXCaovLP5fg6aKkbF2a11Q6M/92tFLJUNN2ymVbazKgq2ULRJEb2Dlr92tpL4QWINNxNzorOP1XKRg15Y= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778695151; c=relaxed/simple; bh=YbspBmQMxMTIBclYq2VU66JGVjEEcgkh1pyOdxj8GdM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=FlkU5aKxiQX7szv8dsDMDAKBAYW3a1X4J3U+YuWYbKov65SkeDdkO7gWTjkPPS1kDB3GKkX1ChdO3pXcER+BVZyGZC5faTrl98LpI/gcM0aJNIRa10gDqJo3FCpGoVAzcSzTgMcMkpTNjDCtN4v95P8/DaAHUNrd7Q7zNWpr7ZA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=gourry.net; spf=pass smtp.mailfrom=gourry.net; dkim=pass (2048-bit key) header.d=gourry.net header.i=@gourry.net header.b=QJspCscF; arc=none smtp.client-ip=209.85.160.175 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=gourry.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gourry.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gourry.net header.i=@gourry.net header.b="QJspCscF" Received: by mail-qt1-f175.google.com with SMTP id d75a77b69052e-50e614fdb42so54905521cf.3 for ; Wed, 13 May 2026 10:59:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1778695148; x=1779299948; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=mQhrTLpOCDPjo0olCcyL9mX4Ei+AK9gfYSunqc4VBE4=; b=QJspCscFVsHYbmDs7ehzVZn5gdpVvExbblekxXigWksTcBGh1B+G71SaY66/HayPJZ vfBsfod3WaZPVrOOcxjqHVEzd2p2+tj7ATO3SNcRVCo8X1psTpHo8nWYsTlSnL7mUk/b vMZ3QZysZ6bALpyvHyapqkAJEDRWo5VAqdaFAtljRd2ZkHFvSQYjjHS7jzO2xGLykIPC ZBsvh+W8MvDi3nBHPggYsRm1ZJTsE9IY/GmswT2qpreQZHdYqIny1FMP3yD2Q9iSPaVo WChru0ASImpdIZeYKRzhR6Wl4dZxZ7D+2TAVDNEiubDgP8MA7AgJqu+iA+8CLMTBQ1y8 EQKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778695148; x=1779299948; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=mQhrTLpOCDPjo0olCcyL9mX4Ei+AK9gfYSunqc4VBE4=; b=s0SFtCJeNgNVJS7fwyPWlqNGIc/1RTo+9TMTK12Qsk2NE9ctWB5qpBJu8PF4YFvQMN xwa8oHw9a2Uu0NoItMl8o2MjWW/Ux/n4JDzOwFHj39GBDF4YAWKmmeFJtbkxb2IkVmHj AjSXOWcX/DVrJ0mzlhDDSnFcfr811UIk+9nZVQBpdU78UMyDxYIh3zBndXeuSkD2wGpz ZSgJy+a1Txx4AZ3XgDOcyQg3wOkBkIyb45LGW0xoMh+d1x0oVNE4GDd5dXPO0+16aAAG sZmLLHoqMYdF7P6wYFxNyfJi411oNI8sxThkikL45tJ6ohCyJPBBIPy4HN9JpL2LPpET zsAg== X-Forwarded-Encrypted: i=1; AFNElJ9BP4MCdYVgNkYh6Lfu4A784gw14QMwU2eedmY8hARu5OtnXbx07uqwioZhDtnNi7LjdHwm9AqOMv7AwfU=@vger.kernel.org X-Gm-Message-State: AOJu0Yx21VYc/of2ul0FLBudBNOBu5Quh23Thsk4NAQ/6ddIi2hWYRpR T7KgR1edhE+rqyNJ4wdoFCQhhvAJ3kipqX+MWezVXX27BmA1Eo3G9kCSleVLypgXPxg= X-Gm-Gg: Acq92OHAUnKI9uOq9TUReVXbvXYUfwvbzqtCCRHb1Yc1JyjQRH+X9siCWkCD0olc8GJ +pdyuIdQVDdqUjeKz8ENLE6YtU03quSk7tI7iSjClUjIY2tezlzbssv/mzvoe3k7EcssxnxUTCS QHHr9NDE2xCZbm0DdrY7K0BTBtBBMIsoPb5alvdN6hBEyEhzBuIu6nvq0HB93068rulQzLGMcgC B9RiWxZeeKlvAUKuKHNFUzKN3z0nvsnLyODQejtVBB1RwKlThtKO2syt8PVBrglwr/lB4419poi rBCRP1lBMGSAUN2dzXJV6mavyESDj1XlTxJS54IUs0SoWfylt0ET0hPZ8IYZVW/jEUFluuYpcQd JwKnofWGpEPiwcOhc+PI5cyFXmxTzOShapq1gsVif1RXBQe36nl24vELrAATRJA4OUAUcwHZ7NF Y/1osv2iGzTTcE8IG/1MPIU7YV6Yqo3tFc8IjZBSiuM9A0RfhS0MuGiapAxGBxnQGs5LckDQyas lVOUD0sKNMXeQvtfM0px08= X-Received: by 2002:a05:622a:4d06:b0:515:189c:e0f8 with SMTP id d75a77b69052e-5162f47a8c4mr55612271cf.17.1778695148579; Wed, 13 May 2026 10:59:08 -0700 (PDT) Received: from gourry-fedora-PF4VCD3F (pool-100-36-248-188.washdc.fios.verizon.net. [100.36.248.188]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-8c908d1d2cfsm2318436d6.15.2026.05.13.10.59.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 May 2026 10:59:08 -0700 (PDT) Date: Wed, 13 May 2026 13:59:06 -0400 From: Gregory Price To: "Vlastimil Babka (SUSE)" Cc: Brendan Jackman , 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 Subject: Re: [PATCH v2 00/22] mm: Add __GFP_UNMAPPED Message-ID: References: <20260320-page_alloc-unmapped-v2-0-28bf1bd54f41@google.com> 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: On Wed, May 13, 2026 at 07:38:01PM +0200, Vlastimil Babka (SUSE) wrote: > 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). > Ah, I follow. If everything is default-unmapped, then you don't have to worry about this issue - except when a stolen block is returned or an ephemeral mapping is unmapped after the operation. pivoting... On the GFP front, i wonder if you could factor out the core of alloc_frozen_pages_noprof() and add alloc_unmapped_pages_noprof() which adds (alloc_flags |= ALLOC_UNMAPPED) instead of adding __GFP_UNMAPPED. I have been considering something similar for __GFP_PRIVATE, but this has the added downside of increasing the surface of the buddy for each new narrow use case (in my case, private nodes, in this case unmapped allocations). unless of course we nip that in the bud with something like struct page * alloc_pages_special(enum buddy_context ctxt, gfp_t gfp_mask, ...) { switch (ctxt) { ... internal-only details about how that case is handled ... } } and just go ahead and allow the buddy to grow internally without adding new gfp flags or an infinite number of interfaces. Of course that means users have to know the context in which they're being allocated. Right now you can kind of "transiently cheat" by passing a GFP flag through a bunch of interfaces and that makes certain allocations reachable - but maybe we should not be encouraging that kind of design for these kinds of allocator extensions? Just spitballing here on the GFP issue since that seems to be coming to a head on multiple fronts. ~Gregory