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

[Yosry Ahmed <yosry@kernel.org>]

> >> >> 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?