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 3B05A1397 for ; Tue, 18 Aug 2026 00:32:48 +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=1787013170; cv=none; b=tJGGU1kjNLsFh4L1QYzkprctddT1Uu43VQkEMUnJIEisV/OxGedUWpq+AhCOTSpGgQEMxuTBjgsgWZi54Am/1dI4OjZh0LzzXKlsPj7DjHle0M73nFtm+NsilZcVVLYRAdCmNpYJym8iJfEywic0bpsWfntf2teIUt4PvCPDCeg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787013170; c=relaxed/simple; bh=BIWriuVsyH+Nm8r3jxtOha30WP+vPRrjc3NtFNJz7Z8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=XR4AQu7Vg1RL4DWbeYbHpa8zEaODQgemQzbYZBq+KBMo//LoyNcPD2LK+VqMNwku8UL3pGylajUPNu5aAU0xeJ9cZeElyGysCDnnROhBlO4fOGnbEJtjUlYfItgsOtl/VG8aoDQlHnUw2De8Yq+DNKVHZ3lJBWRr6KbAO9qPxKU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ie6L51uf; 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="ie6L51uf" Received: by smtp.kernel.org (Postfix) with ESMTPSA id ACBBF1F000E9; Tue, 18 Aug 2026 00:32:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1787013168; bh=pAhtcjiaFVrE0ywuLRW1Px4yu/0k1kE0rELQe/mJriA=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=ie6L51ufym0dAHEYODXHB2J0HJZF6QeEQ2IpjdW36OMH+CwwrPS9rRkBxlraiBxSo 4O7/VXaNY4jctmVCuSm+K+UU1drxfv8gnc/qj4xZ77752KBWQoV5lkY4pH01x8xttB kDWhQ5eUqdOeTpezt8zx3yzzUKjQz1tQ7fWfnE6aGMRtl+jgTrlhMxIHmXoRJDyrUd cxOhQ7aV7Bjuz1Y+N9C4is1kHmozJp92+DruyjMp6W0UFTIgiDOLfV55stYTg/4Lkt y6nFIidmOhRRJ1QgD52A2njWq2UcWkLau+pUGgxOVB69PxNBdmzaXJAGO+ORTTV3q6 zCQ0qQanElyGw== Date: Tue, 18 Aug 2026 00:32:46 +0000 From: Yosry Ahmed To: Brendan Jackman Cc: Brendan Jackman , 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, patrick.roy@linux.dev, "Itazuri, Takahiro" , Andy Lutomirski , David Kaplan , Thomas Gleixner , Patrick Bellasi , Reiji Watanabe , Sean Christopherson , Nikita Kalyazin , Ackerley Tng 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: > >> >> diff --git a/mm/mlock.c b/mm/mlock.c > >> >> index efa6716e4dfbd..045b6779440b1 100644 > >> >> --- a/mm/mlock.c > >> >> +++ b/mm/mlock.c > >> >> @@ -474,7 +474,7 @@ static int mlock_fixup(struct vma_iterator *vmi, struct vm_area_struct *vma, > >> >> int ret = 0; > >> >> > >> >> if (vma_flags_same_pair(&old_vma_flags, new_vma_flags) || > >> >> - vma_is_secretmem(vma) || !vma_supports_mlock(vma)) { > >> >> + vma_has_no_direct_map(vma) || !vma_supports_mlock(vma)) { > >> > > >> > I don't think this one is correct. From commit 1507f51255c9 ("mm: > >> > introduce memfd_secret system call to create "secret" memory areas"): > >> > > >> > Since the secretmem mappings are locked in memory they cannot exceed > >> > RLIMIT_MEMLOCK. Since these mappings are already locked independently > >> > from mlock(), an attempt to mlock()/munlock() secretmem range would > >> > fail and mlockall()/munlockall() will ignore secretmem mappings. > >> > > >> > Seems like secretmem pages are just mlock()'d by default, hence the > >> > check here. Maybe this also works for guest_memfd, but I don't think > >> > it's a generalization that any pages without a direct mapping should > >> > receive the same treatment here. > >> > >> Ack, yeah this sounds correct to me. > >> > >> I guess you could argue something like "the reason secretmem is > >> implicitly mlocked is that it can't be reclaimed, because there's no > >> direct map". But that doesn't generalise IMO, you could imagine letting > >> the user say "remove this memory from the direct map, but I trust my > >> swap system, you can swap it" and then use the mermap to implement > >> reclaim. > > > > Exactly, I don't think no direct mapping implicitly means unreclaimable. > > I don't think you actually need a direct mapping to read/write from > > disk to memory? > > Oh. I never thought about that! I suppose the DMA is gonna happen via > some other address space, either it's via an IOMMU or it works directly > on physical RAM. So the kernel's direct map is irrelevant... Is that > universal though? There must be cases where the CPU's mappings still > matter... Umm... needs more research! > > (Don't think this blocks anything in this series though, let me know if > you disagree...) I think we probably just wanna keep the secretmem check here instead of generalizing to all unmapped pages being mlocked?