Re: VMA merging updateds?

["Jarkko Sakkinen" <jarkko@kernel.org>]

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.

BR, Jarkko