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 5DF205C613 for ; Sat, 8 Aug 2026 00:19:18 +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=1786148359; cv=none; b=hvFZh1L+p9rNWFVT5z65WI9FwZyWegWT3U0tkFpWzn1eNtS5zoyyUhR/44tveeVZKTOJitLDQGweTjS/UWGCx9szoLYmzVRp8nuP8p8KBl/u4B6bc7DfGLXSxw6eELjkDvbwaCHVuu6rfJk8yuOmGyRNNHa3xjlg2G5OtCM3fBM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786148359; c=relaxed/simple; bh=1Qn6bLm5XlrRbDn3BcdXs70mo9GabPjHL++sS9VNGwk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=XBaX/YZ76ey7yZ56q+RuQOKNSP7HXGArUcszlw5o2h3AIVvgLOvzvCRhaGukLYCTPxpeMoJ06ytnjY0UUSBYd07CPySthMbOk9axVxTYpbqxVy4DcmdajhmKhKwBvPZr0HB12dC3uCgpado5J24IRU7zLYhlR5pVWX678u/6r3M= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=AEcamcDg; 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="AEcamcDg" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E5DA11F000E9; Sat, 8 Aug 2026 00:19:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786148358; bh=fTh+tlr+MLwVhLjQqoQiJDfHy6vLLNfFF0nfrsGeNks=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=AEcamcDgQI/AsYPr1XCKo5dgYxuYDyLUh8ZtZaIZ3eW9VTnIuvHyym6sFow+V+EmJ BF/EC2CPLtBSLgmPX6/6yjyEdHeoRDl/w577EI29kncY8HueOnXAfUDmLNu1ATrBK0 9ZHnpUTzm6ZDI+IUC2S3qusrId8dd939bIuBbpV6wqmH5toMuH+v5IRoDmAAIC8NJa ZnCIe/9qy7oR0D+Vma5F7lQV9JJQ/WHEISQwrjawugi+3KAdfa5HZJkwWNdtB4zmLK 6Oj6DMWXxTgkA/N+f109WJn8XhQmPW/lxnxAfz2oaKrLa+dwH1XPSgkyKAkdJZ4FlO V0E1EDno6R1YQ== Date: Sat, 8 Aug 2026 00:19:15 +0000 From: Yosry Ahmed To: Brendan Jackman , Brendan Jackman Cc: Borislav Petkov , Dave Hansen , Peter Zijlstra , Andrew Morton , David Hildenbrand , Vlastimil Babka , Mike Rapoport , Wei Xu , Johannes Weiner , Zi Yan , Lorenzo Stoakes , linux-mm@kvack.org, linux-kernel@vger.kernel.org, x86@kernel.org, Sumit Garg , Will Deacon , rientjes@google.com, "Kalyazin, Nikita" , patrick.roy@linux.dev, "Itazuri, Takahiro" , Andy Lutomirski , David Kaplan , Thomas Gleixner , Patrick Bellasi , Reiji Watanabe , Sean Christopherson , Nikita Kalyazin Subject: Re: [PATCH v3 03/26] mm: introduce AS_NO_DIRECT_MAP Message-ID: References: <20260726-page_alloc-unmapped-v3-0-6f5729aa9832@google.com> <20260726-page_alloc-unmapped-v3-3-6f5729aa9832@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: <20260726-page_alloc-unmapped-v3-3-6f5729aa9832@google.com> On Sun, Jul 26, 2026 at 10:22:36PM +0000, Brendan Jackman wrote: > From: Patrick Roy > > 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. > > 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 > Signed-off-by: Nikita Kalyazin > [Moved zapping to page cache; removed review tags] > Signed-off-by: Brendan Jackman > --- [..] > /** > * filemap_remove_folio - Remove folio from page cache. > * @folio: The folio. > @@ -260,6 +309,8 @@ void filemap_remove_folio(struct folio *folio) > inode_lru_list_add(mapping->host); > spin_unlock(&mapping->host->i_lock); > > + prep_remove_unmapped_folio(mapping, folio); Does this miss callers that call __filemap_remove_folio() directly? We can't just move the call into __filemap_remove_folio() as it will later include a TLB shootdown and (at least) some of the callers have IRQs disabled. > + > filemap_free_folio(mapping, folio); > }