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@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.
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.
