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 3370121D3E2; Thu, 28 Aug 2025 14:26:48 +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=1756391209; cv=none; b=TeTtQadAkVeUtipVjpSZlpA5HeH+p6XfQsfS9PD7Isrs6ltCIkS7/tlYHNjXsx2zuQ/4V/tZKHCctqnMDjiLy6gJUZ91DSmh0V4cGz8z77YB2SP9nwamwkA4bNIDmOsb2TWRvRfD0+6FxQdHcrMy32ZPlEYs7KW8AGkni7WUJNk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1756391209; c=relaxed/simple; bh=p5P8kAChBoN4WOlr76oijnY83blpFKG+JTaA6cgwwtY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=itE8P5b8LnxL18z2dJ8yuF954Nb2gy1bdHMCi5Hrsf9SFPAIRWkmb/AudUBCDtVBO1SrYFGI70Y9zCLW6l/xwgQcNvQrMscD06x+vcNQcdgrxKkauvzJyAguyHQkZeOBMLsq5zKGlm/EntJQdXX0CIY3jX9fnZKcfl5PPIknruA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=c7kEKCt2; 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="c7kEKCt2" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 60BB8C4CEF5; Thu, 28 Aug 2025 14:26:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1756391208; bh=p5P8kAChBoN4WOlr76oijnY83blpFKG+JTaA6cgwwtY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=c7kEKCt2emu8+T6n7qTfSORifJVoKQh2kg28pFXSWr0eYZyb/w6+Pb4ykjBXYLmm9 97jHgUVhwZWTzkgi/woAxVcFRSqNt76KPpYDjEo/EUHeq+X7Or7nKTgZZb078U0ARQ no/xsYpiTG0WZghM96EE7TUKcqUIvqG8ZqxE6LONBXzI1oEaB9ZSsCRi7YWonu52OK mYiGeIi4SmfWeptkTfY28Z5aL5e89Ptp3Wk4NECmiBSY/evwNnIG9qPCfRMJj6YBEZ 6xmANqqFEBrWPu+TgH7qlb/qozJe2OIv7rCaHx2IOvLG89vU7gWDeCHQGwDqPHiGPU Ijmj0CkpirSdg== Date: Thu, 28 Aug 2025 17:26:39 +0300 From: Mike Rapoport To: "Roy, Patrick" Cc: "david@redhat.com" , "seanjc@google.com" , "tabba@google.com" , "ackerleytng@google.com" , "pbonzini@redhat.com" , "kvm@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "kvmarm@lists.linux.dev" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "will@kernel.org" , "vbabka@suse.cz" , "Cali, Marco" , "Kalyazin, Nikita" , "Thomson, Jack" , "Manwaring, Derek" Subject: Re: [PATCH v5 03/12] mm: introduce AS_NO_DIRECT_MAP Message-ID: References: <20250828093902.2719-1-roypat@amazon.co.uk> <20250828093902.2719-4-roypat@amazon.co.uk> Precedence: bulk X-Mailing-List: kvm@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: <20250828093902.2719-4-roypat@amazon.co.uk> On Thu, Aug 28, 2025 at 09:39:19AM +0000, Roy, Patrick wrote: > Add AS_NO_DIRECT_MAP for mappings where direct map entries of folios are > set to not present . Currently, mappings that match this description are > secretmem mappings (memfd_secret()). Later, some guest_memfd > configurations will also fall into this category. > > Reject this new type of mappings in all locations that currently reject > secretmem mappings, on the assumption that if secretmem mappings are > rejected somewhere, it is precisely because of an inability to deal with > folios without direct map entries, and then make memfd_secret() use > AS_NO_DIRECT_MAP on its address_space to drop its special > vma_is_secretmem()/secretmem_mapping() checks. > > This drops a optimization in gup_fast_folio_allowed() where > secretmem_mapping() was only called if CONFIG_SECRETMEM=y. secretmem is > enabled by default since commit b758fe6df50d ("mm/secretmem: make it on > by default"), so the secretmem check did not actually end up elided in > most cases anymore anyway. > > Use a new flag instead of overloading AS_INACCESSIBLE (which is already > set by guest_memfd) because not all guest_memfd mappings will end up > being direct map removed (e.g. in pKVM setups, parts of guest_memfd that > can be mapped to userspace should also be GUP-able, and generally not > have restrictions on who can access it). > > Signed-off-by: Patrick Roy > --- > include/linux/pagemap.h | 16 ++++++++++++++++ > include/linux/secretmem.h | 18 ------------------ > lib/buildid.c | 4 ++-- > mm/gup.c | 14 +++----------- > mm/mlock.c | 2 +- > mm/secretmem.c | 6 +----- > 6 files changed, 23 insertions(+), 37 deletions(-) > > diff --git a/include/linux/secretmem.h b/include/linux/secretmem.h > index e918f96881f5..0ae1fb057b3d 100644 > --- a/include/linux/secretmem.h > +++ b/include/linux/secretmem.h > @@ -4,28 +4,10 @@ > > #ifdef CONFIG_SECRETMEM > > -extern const struct address_space_operations secretmem_aops; Please also make secretmem_aops static in mm/secretmem.c > -static inline bool secretmem_mapping(struct address_space *mapping) > -{ > - return mapping->a_ops == &secretmem_aops; > -} > - ... > diff --git a/mm/gup.c b/mm/gup.c > index adffe663594d..8c988e076e5d 100644 > --- a/mm/gup.c > +++ b/mm/gup.c > @@ -1234,7 +1234,7 @@ static int check_vma_flags(struct vm_area_struct *vma, unsigned long gup_flags) > if ((gup_flags & FOLL_SPLIT_PMD) && is_vm_hugetlb_page(vma)) > return -EOPNOTSUPP; > > - if (vma_is_secretmem(vma)) > + if (vma_is_no_direct_map(vma)) > return -EFAULT; > > if (write) { > @@ -2751,7 +2751,6 @@ static bool gup_fast_folio_allowed(struct folio *folio, unsigned int flags) > { > bool reject_file_backed = false; > struct address_space *mapping; > - bool check_secretmem = false; > unsigned long mapping_flags; > > /* > @@ -2763,14 +2762,6 @@ static bool gup_fast_folio_allowed(struct folio *folio, unsigned int flags) > reject_file_backed = true; > > /* We hold a folio reference, so we can safely access folio fields. */ > - > - /* secretmem folios are always order-0 folios. */ > - if (IS_ENABLED(CONFIG_SECRETMEM) && !folio_test_large(folio)) > - check_secretmem = true; > - > - if (!reject_file_backed && !check_secretmem) > - return true; > - > if (WARN_ON_ONCE(folio_test_slab(folio))) > return false; There's a check for hugetlb after this and a comment there mentions secretmem, please update that to "mapping with no direct map" or something like that. -- Sincerely yours, Mike.