* VMA's not getting merged @ 2022-05-15 1:20 Jarkko Sakkinen 2022-05-16 14:13 ` Dave Hansen 0 siblings, 1 reply; 6+ messages in thread From: Jarkko Sakkinen @ 2022-05-15 1:20 UTC (permalink / raw) To: linux-sgx; +Cc: dave.hansen@linux.intel.com, reinette.chatre Looks like VMA's do not get merged properly: 7f8f00000000-7f8f00009000 r--s 00000000 00:05 84 /dev/sgx_enclave 7f8f00009000-7f8f00034000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f00034000-7f8f000ff000 r-xs 00000000 00:05 84 /dev/sgx_enclave 7f8f000ff000-7f8f00201000 ---p 00000000 00:00 0 7f8f00201000-7f8f003fc000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f003fc000-7f8f003fd000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f003fd000-7f8f00400000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f00400000-7f8f00643000 r--s 00000000 00:05 84 /dev/sgx_enclave 7f8f00643000-7f8f0197b000 r-xs 00000000 00:05 84 /dev/sgx_enclave 7f8f0197b000-7f8f01bab000 r--s 00000000 00:05 84 /dev/sgx_enclave 7f8f01bab000-7f8f01fa7000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f01fa7000-7f8f08000000 ---p 00000000 00:00 0 7f8f08000000-7f8f08001000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f08001000-7f8f08003000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f08003000-7f8f08006000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f08006000-7f8f0800b000 rw-s 00000000 00:05 84 /dev/sgx_enclave 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 7f8f0804e000-7f8f0804f000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f0804f000-7f8f08050000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f08050000-7f8f08051000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f08051000-7f8f08052000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f08052000-7f8f08053000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f08053000-7f8f08054000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f08054000-7f8f08055000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f08055000-7f8f08056000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f08056000-7f8f08057000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f08057000-7f8f08058000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f08058000-7f8f08059000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f08059000-7f8f0805a000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f0805a000-7f8f0805b000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f0805b000-7f8f0805c000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f0805c000-7f8f0805d000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f0805d000-7f8f0805e000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f0805e000-7f8f0805f000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f0805f000-7f8f08060000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f08060000-7f8f08062000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f08062000-7f8f08063000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f08063000-7f8f08064000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f08064000-7f8f08065000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f08065000-7f8f08066000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f08066000-7f8f08067000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f08067000-7f8f08068000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f08068000-7f8f08069000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f08069000-7f8f0806a000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f0806a000-7f8f0806b000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f0806b000-7f8f0806c000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f0806c000-7f8f0806d000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f0806d000-7f8f0806e000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f0806e000-7f8f0806f000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f0806f000-7f8f08070000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f08070000-7f8f08071000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f08071000-7f8f08072000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f08072000-7f8f08081000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f08081000-7f8f08082000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f08082000-7f8f08083000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f08083000-7f8f08084000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f08084000-7f8f08085000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f08085000-7f8f08086000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f08086000-7f8f08087000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f08087000-7f8f08088000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f08088000-7f8f08089000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f08089000-7f8f0808a000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f0808a000-7f8f0808b000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f0808b000-7f8f0809a000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f0809a000-7f8f0809c000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f0809c000-7f8f0809d000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f0809d000-7f8f0809e000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f0809e000-7f8f080a0000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f080a0000-7f8f080a3000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f080a3000-7f8f080a9000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f080a9000-7f8f080b5000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f080b5000-7f8f080c0000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f080c0000-7f8f080c6000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f080c6000-7f8f080d1000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f080d1000-7f8f080dd000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f080dd000-7f8f080f4000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f080f4000-7f8f08121000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f08121000-7f8f0814a000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f0814a000-7f8f08162000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f08162000-7f8f08177000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f08177000-7f8f081a0000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f081a0000-7f8f081c1000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f081c1000-7f8f081d6000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f081d6000-7f8f081ff000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f081ff000-7f8f08228000 rw-s 00000000 00:05 84 /dev/sgx_enclave 7f8f08228000-7f8ffffff000 ---p 00000000 00:00 0 7f8ffffff000-7f9000000000 rw-s 00000000 00:05 84 /dev/sgx_enclave BR, Jarkko ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: VMA's not getting merged 2022-05-15 1:20 VMA's not getting merged Jarkko Sakkinen @ 2022-05-16 14:13 ` Dave Hansen 2022-05-16 18:45 ` Jarkko Sakkinen 0 siblings, 1 reply; 6+ messages in thread From: Dave Hansen @ 2022-05-16 14:13 UTC (permalink / raw) To: Jarkko Sakkinen, linux-sgx; +Cc: dave.hansen@linux.intel.com, reinette.chatre 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: VMA's not getting merged 2022-05-16 14:13 ` Dave Hansen @ 2022-05-16 18:45 ` Jarkko Sakkinen 2022-05-18 0:47 ` Jarkko Sakkinen 0 siblings, 1 reply; 6+ messages in thread From: Jarkko Sakkinen @ 2022-05-16 18:45 UTC (permalink / raw) To: Dave Hansen; +Cc: linux-sgx, dave.hansen@linux.intel.com, reinette.chatre 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: VMA's not getting merged 2022-05-16 18:45 ` Jarkko Sakkinen @ 2022-05-18 0:47 ` Jarkko Sakkinen 2022-06-06 7:21 ` Jarkko Sakkinen 0 siblings, 1 reply; 6+ messages in thread From: Jarkko Sakkinen @ 2022-05-18 0:47 UTC (permalink / raw) To: Dave Hansen; +Cc: linux-sgx, dave.hansen@linux.intel.com, reinette.chatre 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: VMA's not getting merged 2022-05-18 0:47 ` Jarkko Sakkinen @ 2022-06-06 7:21 ` Jarkko Sakkinen 2022-06-06 11:40 ` Jarkko Sakkinen 0 siblings, 1 reply; 6+ messages in thread From: Jarkko Sakkinen @ 2022-06-06 7:21 UTC (permalink / raw) To: Dave Hansen Cc: linux-sgx, dave.hansen@linux.intel.com, reinette.chatre, Nathaniel McCallum, Christopherson,, Sean On Wed, May 18, 2022 at 03:47:32AM +0300, Jarkko Sakkinen wrote: > 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: > [SNIP] I started looking into this again by writing a short program: // SPDX-License-Identifier: GPL-2.0 /* Derivative of tools/testing/selftests/sgx */ #include <fcntl.h> #include <stdint.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <unistd.h> #include <sys/ioctl.h> #include <sys/mman.h> #include <asm/sgx.h> #define ENCL_SIZE (1 << 24) /* 16 MB */ struct sgx_secs { __u64 size; __u64 base; __u32 ssa_frame_size; __u32 miscselect; __u8 reserved1[24]; __u64 attributes; __u64 xfrm; __u32 mrenclave[8]; __u8 reserved2[32]; __u32 mrsigner[8]; __u8 reserved3[32]; __u32 config_id[16]; __u16 isv_prod_id; __u16 isv_svn; __u16 config_svn; __u8 reserved4[3834]; } __attribute__((packed)); void dump_maps(void) { char maps_line[256]; FILE *fp = fopen("/proc/self/maps", "r"); if (fp != NULL) { while (fgets(maps_line, sizeof(maps_line), fp) != NULL) { maps_line[strlen(maps_line) - 1] = '\0'; if (strstr(maps_line, "/dev/sgx_enclave")) printf("%s\n", maps_line); } fclose(fp); } } int main(void) { const char device_path[] = "/dev/sgx_enclave"; struct sgx_enclave_create ioc; struct sgx_secs secs; int fd = -1; void *area; void *addr; int ret; area = mmap(NULL, ENCL_SIZE * 2, PROT_NONE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); if (area == MAP_FAILED) { perror("mmap"); exit(1); } memset(&secs, 0, sizeof(secs)); secs.ssa_frame_size = 1; secs.attributes = 4; secs.xfrm = 3; secs.base = ((uint64_t)area + ENCL_SIZE - 1) & ~(ENCL_SIZE - 1); secs.size = ENCL_SIZE; munmap(area, secs.base - (uint64_t)area); munmap((void *)(secs.base + ENCL_SIZE), (uint64_t)area + ENCL_SIZE - secs.base); fd = open(device_path, O_RDWR); if (fd < 0) { perror("open"); exit(1); } ioc.src = (unsigned long)&secs; ret = ioctl(fd, SGX_IOC_ENCLAVE_CREATE, &ioc); if (ret) { perror("ioctl"); exit(1); } addr = mmap((void *)secs.base, ENCL_SIZE / 2, PROT_READ | PROT_WRITE, MAP_SHARED | MAP_FIXED, fd, 0); if (addr == MAP_FAILED) { perror("mmap"); exit(1); } addr = mmap((void *)(secs.base + ENCL_SIZE / 4), ENCL_SIZE / 2, PROT_READ | PROT_WRITE, MAP_SHARED | MAP_FIXED, fd, 0); if (addr == MAP_FAILED) { perror("mmap"); exit(1); } dump_maps(); exit(0); } It creates two RW VMA's: 1. 8 MB VMA. 2. Another 8 MB VMA that overlaps the first by 4 MB. Expected result ought to be 12 MB RW VMA. Then I wrote a another eBPF script: #include <linux/fs.h> #include <linux/mm.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]/ { printf("vma_merge: retval = %d\n", retval); } k:__vma_adjust /strncmp(str(((struct vm_area_struct *)arg0)->vm_file->f_path.dentry->d_name.name), "sgx_enclave", 11) == 0/ { @adjust[tid] = true; } kr:__vma_adjust /@adjust[tid]/ { printf("__vma_adjust: retval = %d\n", retval); } kr:__mpol_equal { printf("__mpol_equal: retval = %d\n", retval); } This gives me: $ sudo bpftrace sgx-vma-merged.bt Attaching 5 probes... __vma_adjust: retval = 0 __vma_adjust: retval = 0 vma_merge: retval = 0 vma_merge: retval = 0 vma_merge: retval = 0 Two __vma_adjust() calls are result of mapping enclave VMA on top of anonymous VMA. __vma_adjust() is never reached when overlapping VMA is mapped. Another noworthy thing is that mpol_equal() is never reached, and the condition in vma_merge is like this: if (prev && prev->vm_end == addr && mpol_equal(vma_policy(prev), policy) && can_vma_merge_after(prev, vm_flags, anon_vma, file, pgoff, vm_userfaultfd_ctx, anon_name)) { So this led to the obvious fact: it's the VM_SPECIAL check in the beginning of the vma_merge() function. I found at least this old ref on removing the close callback: https://lore.kernel.org/linux-sgx/20190708145707.GC20433@linux.intel.com/ So I guess we did not take this VM_SPECIAL check in the account... On bright side: this can be obviously worked around in the user space. E.g. in "brk()" you do mmap() over the whole new VMA instead of the new subportion of it, and so forth. And all in all the whole merging thing can be worked around in the user space. So it's not a dead end but still would be nice to have kernel to do this automatically. Dave: so my question is this: can VM_SPECIAL check be relaxed somehow, or should it be just documented that enclave VMAs do not get merged? Anyway, if this was a blocker for getting SGX2 patches to 5.19, it should not be. I did all the research with my i5-9600KF desktop, which is oddbal CPU with flexible launch control, and no SGX2. Neither was any SGX2 patches applied. BR, Jarkko ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: VMA's not getting merged 2022-06-06 7:21 ` Jarkko Sakkinen @ 2022-06-06 11:40 ` Jarkko Sakkinen 0 siblings, 0 replies; 6+ messages in thread From: Jarkko Sakkinen @ 2022-06-06 11:40 UTC (permalink / raw) To: Dave Hansen Cc: linux-sgx, dave.hansen@linux.intel.com, reinette.chatre, Nathaniel McCallum, Christopherson,, Sean On Mon, Jun 06, 2022 at 10:21:15AM +0300, Jarkko Sakkinen wrote: > Dave: so my question is this: can VM_SPECIAL check be > relaxed somehow, or should it be just documented that > enclave VMAs do not get merged? The special check feels a bit odd for me, given that 1. It's hard to imagine anything that would not be "special", and still would implement vma_close(). I presume that something like this exists. Just cannot make up anything. 2. On the other hand, is_mergeable_vma() pretty much sets the constraints to merge to VMA's into one. Most importantly it checks that vm_close() is not implemented and VMA's map the same file. BR, Jarkko ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2022-06-06 11:42 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2022-05-15 1:20 VMA's not getting merged Jarkko Sakkinen 2022-05-16 14:13 ` Dave Hansen 2022-05-16 18:45 ` Jarkko Sakkinen 2022-05-18 0:47 ` Jarkko Sakkinen 2022-06-06 7:21 ` Jarkko Sakkinen 2022-06-06 11:40 ` Jarkko Sakkinen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox