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@xxxxxxxxxx/ > > > > > > 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
