Re: [PATCH v3 03/26] mm: introduce AS_NO_DIRECT_MAP

[Brendan Jackman]

On Tue Aug 18, 2026 at 2:32 AM CEST, Yosry Ahmed wrote:
>> >> >> 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?

Oh yeah I think so too. The above is all just pondering longer-term
questions.