Re: VMA merging updateds?

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

On 26/09/2024 12:33 pm, Jarkko Sakkinen wrote:
> 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.
> 

Is there any real problem if we don't do this at all (neither in core mm 
nor in userspace)?