Re: VMA merging updateds?

["Jarkko Sakkinen" <jarkko.sakkinen@iki.fi>]

On Thu Sep 26, 2024 at 3:07 AM EEST, Kai Huang wrote:
>
>
> On 23/09/2024 7:48 pm, Jarkko Sakkinen wrote:
> > On Sun Sep 22, 2024 at 7:57 PM EEST, Jarkko Sakkinen wrote:
> >>> On Sun Sep 22, 2024 at 7:27 PM EEST, Jarkko Sakkinen wrote:
> >>>> Hi
> >>>>
> >>>> I started to look into this old issue with mm subsystem and SGX, i.e.
> >>>> can we make SGX VMA's to merge together?
> >>>>
> >>>> This demonstrates the problem pretty well:
> >>>>
> >>>> https://lore.kernel.org/linux-sgx/884c7ea454cf2eb0ba2e95f7c25bd42018824f97.camel@kernel.org/
> >>>>
> >>>> It was result of brk() syscall being applied a few times.
> >>
> >> Briging some context here. This can be fixed in the run-time by book
> >> keeping the ranges and doing unmapping/mapping. I guess this goes
> >> beyond what mm should support?
> >>
> >> I thought to plain check this as it has been two years since my last
> >> query on topic (if we could improve either the driver or mm somehow).
> > 
> > In the past I've substituted kernel's mm merge code with user space
> > replacement:
> > 
> > https://github.com/enarx/mmledger/blob/main/src/lib.rs
> > 
> > It's essentially a reimplementation of al stuff that goes into
> > mm/mmap.c's vma_merge(). I cannot recall anymore whether merges
> > which map over existing ranges were working correctly, i.e. was
> > the issue only concerning adjacent VMA's.
> > 
> > What I'm looking here is that can we make some cosntraints that
> > if satisfied by the pfnmap code, it could leverage the code from
> > vma_merge(). Perhaps by making explicit call to vma_merge()?
> > I get that implicit use moves too much responsibility to the mm
> > subsystem.
> > 
>
> Hi Jarkko,
>
> Just want to understand more on the background:
>
> Are you seeing any real problem due to needing a lot of mmap()s to the 
> same enclave, or it is just a problem that doesn't look nice and you 
> want to resolve?
>
> I mean, this problem doesn't seem to be SGX-specific but a common one 
> for VMAs with VM_PFNMAP (any bit in VM_SPECIAL), e.g., from random 
> device drivers with mmap() support.  We will need a good justification 
> if we want to make any core-mm change, if any, for this.

It requires essentially replicating core mm in user space.

It's a manageable problem but feels silly since logic in merging
is mostly 1:1. It's not a problem for me personally as I'm not
making any money from SGX (more so to Intel).

BR, Jarkko