On Mon, May 16, 2022 at 09:45:56PM +0300, Jarkko Sakkinen wrote:
> On Mon, May 16, 2022 at 07:13:42AM -0700, Dave Hansen wrote:
> > On 5/14/22 18:20, Jarkko Sakkinen wrote:
> > > Looks like VMA's do not get merged properly:
> > ...
> > > 7f8f0800b000-7f8f08014000 rw-s 00000000 00:05 84 /dev/sgx_enclave
> > > 7f8f08014000-7f8f08025000 rw-s 00000000 00:05 84 /dev/sgx_enclave
> > > 7f8f08025000-7f8f08046000 rw-s 00000000 00:05 84 /dev/sgx_enclave
> > > 7f8f08046000-7f8f0804a000 rw-s 00000000 00:05 84 /dev/sgx_enclave
> > > 7f8f0804a000-7f8f0804b000 rw-s 00000000 00:05 84 /dev/sgx_enclave
> > > 7f8f0804b000-7f8f0804c000 rw-s 00000000 00:05 84 /dev/sgx_enclave
> > > 7f8f0804c000-7f8f0804d000 rw-s 00000000 00:05 84 /dev/sgx_enclave
> > > 7f8f0804d000-7f8f0804e000 rw-s 00000000 00:05 84 /dev/sgx_enclave
> >
> > I remember some issue with VM_IO VMAs not getting merged, but I don't
> > remember how we fixed or addressed it.
> >
> > Seems like something we can and should fix, though.
>
> Access pattern here is series of small adjacent mmaps (brk()).
>
> During upstreaming vma_close callback was eliminated to allow VMA's getting
> merged. I'll try to trace the condition in the call path triggering this.
>
> BR, Jarkko
I wrote a small bpftrace script:
#include <linux/fs.h>
k:vma_merge
/strncmp(str(((struct vm_area_struct *)arg1)->vm_file->f_path.dentry->d_name.name), "sgx_enclave", 11) == 0/
{
@merge[tid] = true;
}
kr:vma_merge /@merge[tid] && retval > 0/
{
@merged = count();
delete(@merge[tid]);
}
kr:vma_merge /@merge[tid]/
{
@unmerged = count();
delete(@merge[tid]);
}
When running with the same payload, I get:
@merged: 0
@unmerged: 209
So it gets down to vma_merge but each time the function returns NULL.
BR, Jarkko
