Re: VMA merging updateds?

["Huang, Kai" <kai.huang@intel.com>]

>>>>>>> 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).
> 
> I.e. in the case when you want do a syscall shim. You fix it up by
> maintaining reflected version of the VMA database in the user space
> and remapping everything based on that for every possible mm-call.
> 
> I've implemented such feature in the past for Enarx so it is entirely
> possible.
> 

Just want to understand the problem/use case better:

I _think_ I got what the "syscall shim" is.  But can you elaborate why 
is this "syscall shim" related to the "kernel unable to merge contiguous 
VMAs for the same enclave"?  Assuming the kernel can actually merge 
enclave VMAs, how does it help on the "syscall shim"?