From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-174.mta0.migadu.com (out-174.mta0.migadu.com [91.218.175.174]) (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 2992E3B8920 for ; Fri, 31 Jul 2026 11:57:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.174 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785499076; cv=none; b=mCcny0duh9RlrObNxEVTHOkWgMwMqqVokALNvLLM/6vdQd6IHjXm8jLOqwyU7/WEu981nVCXwady8VvHhGT3MzUJUdcAnw2ttOBxoN5xFCU9K3hvM1vigt0l5kP7eGc298k4GLtDStaKD4cCdEqCZzChOy7H5BQkprlzYcmBaWo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785499076; c=relaxed/simple; bh=HulRgZgpu0humrHg66N4nBDU1BXo0lGGpu2GyasTp80=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:Subject:From:To: References:In-Reply-To; b=lRcUxXy+qraKDkN/Y0lYBpFCp2fFgtNhogXRkdyB7Ir1jpwxbQBDJND0uBNHtFcePLzg84hxM+CN2bHc0pVkCeV47dR7kiRVEO/RGXlibsiH7BdXx1y8LXm2BpYq0cuBmnlNx4iNAokS4o+QlZk5hLoMDsNwhHckzTZA1wjjEDg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=Xr4jU4cT; arc=none smtp.client-ip=91.218.175.174 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="Xr4jU4cT" Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1785499071; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=qnM+fZMqOTfOvPya0w0t8FJWn6k/GbvAR7xBXXOi7v0=; b=Xr4jU4cTlta8FK2nH1n38sVAnWN5KkXMYZq8JZ5Ke+g0wKDofFqEvav2sSCK4fbJHu4+8r 9QFBwADJbIN0Y69wzG6Tyt2u3Di4b2Jv5qfS1A4kzvf+SP4pGyM+FA6Ej7g9glxZXn15Q6 Od30JIHbA7eiinUkmVe99Fb9LLv/FZA= Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Fri, 31 Jul 2026 11:57:33 +0000 Message-Id: Cc: "Brendan Jackman" , "Borislav Petkov" , "Dave Hansen" , "Peter Zijlstra" , "Andrew Morton" , "David Hildenbrand" , "Vlastimil Babka" , "Wei Xu" , "Johannes Weiner" , "Zi Yan" , "Lorenzo Stoakes" , , , , "Sumit Garg" , "Will Deacon" , , "Kalyazin, Nikita" , , "Itazuri, Takahiro" , "Andy Lutomirski" , "David Kaplan" , "Thomas Gleixner" , "Patrick Bellasi" , "Reiji Watanabe" , "Sean Christopherson" , "Nikita Kalyazin" Subject: Re: [PATCH v3 01/26] set_memory: add folio_{zap,restore}_direct_map helpers X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: "Brendan Jackman" To: "Mike Rapoport" , "Yosry Ahmed" References: <20260726-page_alloc-unmapped-v3-0-6f5729aa9832@google.com> <20260726-page_alloc-unmapped-v3-1-6f5729aa9832@google.com> In-Reply-To: X-Migadu-Flow: FLOW_OUT On Fri Jul 31, 2026 at 5:21 AM UTC, Mike Rapoport wrote: > On Thu, Jul 30, 2026 at 08:34:57PM +0000, Yosry Ahmed wrote: >> On Sun, Jul 26, 2026 at 10:22:34PM +0000, Brendan Jackman wrote: >> > From: Nikita Kalyazin >> >=20 >> > Let's provide folio_{zap,restore}_direct_map helpers as preparation fo= r >> > supporting removal of the direct map for guest_memfd folios. >> > In folio_zap_direct_map(), flush TLB to make sure the data is not >> > accessible. On some architectures, there may be a double TLB flush >> > issued because set_direct_map_valid_noflush already performs a flush >> > internally. >> >=20 >> > The new helpers need to be accessible to KVM on architectures that >> > support guest_memfd (x86 and arm64). >> >=20 >> > Direct map removal gives guest_memfd the same protection that >> > memfd_secret does, such as hardening against Spectre-like attacks >> > through in-kernel gadgets. >> >=20 >> > Acked-by: David Hildenbrand (Arm) >> > Signed-off-by: Nikita Kalyazin >> > [Added comment, dropped modified set_direct_map API, added highmem che= ck] >> > Signed-off-by: Brendan Jackman >> > --- >> > include/linux/set_memory.h | 13 +++++++++++++ >> > mm/memory.c | 46 +++++++++++++++++++++++++++++++++++++= +++++++++ >> > 2 files changed, 59 insertions(+) >> >=20 >> > diff --git a/include/linux/set_memory.h b/include/linux/set_memory.h >> > index 3030d9245f5ac..1bf2a15bca118 100644 >> > --- a/include/linux/set_memory.h >> > +++ b/include/linux/set_memory.h >> > @@ -40,6 +40,15 @@ static inline int set_direct_map_valid_noflush(stru= ct page *page, >> > return 0; >> > } >> > =20 >> > +static inline int folio_zap_direct_map(struct folio *folio) >> > +{ >> > + return 0; >>=20 >> Should this return an error (e.g. -EOPNOTSUPP)? Seems like it would >> silently succeed if the arch doesn't actually support removing from the >> direct map. > > That's the pattern we have now for all set_memory APIs. Yeah. And I think that's fine, the risk of silent failure is mitigated by: #define can_set_direct_map() false So yes code could call folio_zap_direct_map() directly and get confusing results on unsupported configs, but that code would be broken on arm64 regardless (coz it didn't respect can_set_direct_map()), plus later in this series is: #ifdef CONFIG_PAGE_ALLOC_UNMAPPED #define ALLOC_UNMAPPED 0x2000 #endif So higher-level code will fail to compile it if uses ALLOC_UNMAPPED on a completely unsupported config.