search for: vmas

...segment so that the dynamic linker has the option to merge the two virtual memory areas at run time. This is an RFC for moving RELRO segment. Currently, lld orders ELF sections in the following order: R, RX, RWX, RW, and RW contains RELRO. At run time, after RELRO is write-protected, we'd have VMAs in the order of: R, RX, RWX, R (RELRO), RW. I'd like to propose that we move RELRO to be immediately after the read-only sections, so that the order of VMAs become: R, R (RELRO), RX, RWX, RW, and the dynamic linker would have the option to merge the two read-only VMAs to reduce bookkeeping cost...

...der would be to add some allocator that > at runtime picks if it uses 32-bit or 64-bit allocator. Hi Jakub, My assumption is based on what I understood from my talks with various people in sanitizers, libraries, GCC, LLVM and the kernel. Please, correct me if I'm wrong. IIUC, using larger VMAs on kernels with smaller VMAs work, but restrict the space that you can use as a shadow region, thus limiting the size of programs you can run with the sanitizers. Also, the higher you go, the higher is the levels of indirection you need to use memory, so using higher VMAs may be more of a performan...

...host/vdpa.c > +++ b/drivers/vhost/vdpa.c > @@ -588,19 +588,21 @@ static int vhost_vdpa_process_iotlb_update(struct vhost_vdpa *v, > struct vhost_dev *dev = &v->vdev; > struct vhost_iotlb *iotlb = dev->iotlb; > struct page **page_list; > - struct vm_area_struct **vmas; > + unsigned long list_size = PAGE_SIZE / sizeof(struct page *); > unsigned int gup_flags = FOLL_LONGTERM; > - unsigned long map_pfn, last_pfn = 0; > - unsigned long npages, lock_limit; > - unsigned long i, nmap = 0; > + unsigned long npages, cur_base, map_pfn, last_pfn = 0; &...

...e alignment is added, the R and RW maps can get contiguous > (non-overlapping) p_offset ranges. However, the RW map is private dirty, > it cannot be merged with adjacent maps so I am not clear how it can save > kernel memory. > My understanding (and my test result shows so) is that two VMAs can be merged even when one of them contains dirty pages. As far as I can tell from reading vma_merge() in mm/mmap.c in Linux kernel, there's nothing preventing merging consecutively mmaped regions in that case. That said, we may not care about this case too much if we decide that this change s...

...r; } @@ -592,21 +594,19 @@ static int vhost_vdpa_process_iotlb_update(struct vhost_vdpa *v, struct vhost_dev *dev = &v->vdev; struct vhost_iotlb *iotlb = dev->iotlb; struct page **page_list; - unsigned long list_size = PAGE_SIZE / sizeof(struct page *); + struct vm_area_struct **vmas; unsigned int gup_flags = FOLL_LONGTERM; - unsigned long npages, cur_base, map_pfn, last_pfn = 0; - unsigned long locked, lock_limit, pinned, i; + unsigned long map_pfn, last_pfn = 0; + unsigned long npages, lock_limit; + unsigned long i, nmap = 0; u64 iova = msg->iova; + long pinned; int...

...r; } @@ -592,21 +594,19 @@ static int vhost_vdpa_process_iotlb_update(struct vhost_vdpa *v, struct vhost_dev *dev = &v->vdev; struct vhost_iotlb *iotlb = dev->iotlb; struct page **page_list; - unsigned long list_size = PAGE_SIZE / sizeof(struct page *); + struct vm_area_struct **vmas; unsigned int gup_flags = FOLL_LONGTERM; - unsigned long npages, cur_base, map_pfn, last_pfn = 0; - unsigned long locked, lock_limit, pinned, i; + unsigned long map_pfn, last_pfn = 0; + unsigned long npages, lock_limit; + unsigned long i, nmap = 0; u64 iova = msg->iova; + long pinned; int...

On Fri 03-07-20 10:34:09, Catangiu, Adrian Costin wrote: > This patch adds logic to the kernel power code to zero out contents of > all MADV_WIPEONSUSPEND VMAs present in the system during its transition > to any suspend state equal or greater/deeper than Suspend-to-memory, > known as S3. How does the application learn that its memory got wiped? S2disk is an async operation and it can happen at any time during the task execution. So how does the ap...

On Fri 03-07-20 10:34:09, Catangiu, Adrian Costin wrote: > This patch adds logic to the kernel power code to zero out contents of > all MADV_WIPEONSUSPEND VMAs present in the system during its transition > to any suspend state equal or greater/deeper than Suspend-to-memory, > known as S3. How does the application learn that its memory got wiped? S2disk is an async operation and it can happen at any time during the task execution. So how does the ap...

...he dynamic linker has the option to merge the two virtual memory areas at run time. >> >> This is an RFC for moving RELRO segment. Currently, lld orders ELF sections in the following order: R, RX, RWX, RW, and RW contains RELRO. At run time, after RELRO is write-protected, we'd have VMAs in the order of: R, RX, RWX, R (RELRO), RW. I'd like to propose that we move RELRO to be immediately after the read-only sections, so that the order of VMAs become: R, R (RELRO), RX, RWX, RW, and the dynamic linker would have the option to merge the two read-only VMAs to reduce bookkeeping cost...

...ave to worry about the interval changing sizes or being removed > while I/O is happening. No, for the 'ODP full process VA' (aka implicit ODP) mode it dynamically maintains a list of intervals. ODP chooses the align the dynamic intervals to it's HW page table levels, and not to SW VMAs. This is much simpler to manage and faster to fault, at the cost of capturing more VA for invalidations which have to be probed against the HW shadow PTEs. > It isn't that expensive, there is an extra driver lock/unlock as > part of the lookup and possibly a find_vma() and kmalloc(GFP_AT...

...which the kernel marks the application sensitive > data as potentially copied, is a secondary objective of this RFC. In > the current PoC proposal, the RFC kernel code combines > MADV_WIPEONSUSPEND semantics with ACPI suspend/wake transitions to zero > out all process pages that fall in VMAs marked as MADV_WIPEONSUSPEND > and thus allow applications and libraries be notified and regenerate > their sensitive data. Marking VMAs as MADV_WIPEONSUSPEND results in > the VMAs being empty in the process after any suspend/wake cycle. > Similar to MADV_WIPEONFORK, if the process acc...

Jakub makes a good point, are you sure that there is no single shadow offset value that works for all VMA variants? What exactly breaks when 1<<36 is used on 42-bit VMA? On Fri, Sep 25, 2015 at 3:28 AM, Yury Gribov via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On 09/25/2015 01:27 PM, Yury Gribov wrote: >> >> On 09/25/2015 11:53 AM, Jakub Jelinek via llvm-dev

...two virtual memory >> areas at run time. >> >> >> >> This is an RFC for moving RELRO segment. Currently, lld orders ELF >> sections in the following order: R, RX, RWX, RW, and RW contains RELRO. At >> run time, after RELRO is write-protected, we'd have VMAs in the order of: >> R, RX, RWX, R (RELRO), RW. I'd like to propose that we move RELRO to be >> immediately after the read-only sections, so that the order of VMAs become: >> R, R (RELRO), RX, RWX, RW, and the dynamic linker would have the option to >> merge the two read-...

...29:22, Jann Horn wrote: > On Fri, Jul 3, 2020 at 1:30 PM Michal Hocko <mhocko at kernel.org> wrote: > > On Fri 03-07-20 10:34:09, Catangiu, Adrian Costin wrote: > > > This patch adds logic to the kernel power code to zero out contents of > > > all MADV_WIPEONSUSPEND VMAs present in the system during its transition > > > to any suspend state equal or greater/deeper than Suspend-to-memory, > > > known as S3. > > > > How does the application learn that its memory got wiped? S2disk is an > > async operation and it can happen at any t...

...29:22, Jann Horn wrote: > On Fri, Jul 3, 2020 at 1:30 PM Michal Hocko <mhocko at kernel.org> wrote: > > On Fri 03-07-20 10:34:09, Catangiu, Adrian Costin wrote: > > > This patch adds logic to the kernel power code to zero out contents of > > > all MADV_WIPEONSUSPEND VMAs present in the system during its transition > > > to any suspend state equal or greater/deeper than Suspend-to-memory, > > > known as S3. > > > > How does the application learn that its memory got wiped? S2disk is an > > async operation and it can happen at any t...

...KBuffer is de-allocated, userspace asks kernel to update region A..B to not map anything (usually triggers a non-recoverable fault). When you want to unify this between hw drivers I strongly suggest to completely start from scratch once more. First of all don't think about those mappings as VMAs, that won't work because VMAs are usually something large. Think of this as individual PTEs controlled by the application. similar how COW mappings and struct pages are handled inside the kernel. Then I would start with the VA allocation manager. You could probably base that on drm_mm. We...

...corresponding smaller page size overlaying the sparse mappings PTEs. How would this look like in amdgpu? > > When you want to unify this between hw drivers I strongly suggest to > completely start from scratch once more. > > First of all don't think about those mappings as VMAs, that won't work > because VMAs are usually something large. Think of this as individual > PTEs controlled by the application. similar how COW mappings and struct > pages are handled inside the kernel. Why do you consider tracking single PTEs superior to tracking VMAs? All the pro...

...interval changing sizes or being removed >> while I/O is happening. > > No, for the 'ODP full process VA' (aka implicit ODP) mode it > dynamically maintains a list of intervals. ODP chooses the align the > dynamic intervals to it's HW page table levels, and not to SW VMAs. > This is much simpler to manage and faster to fault, at the cost of > capturing more VA for invalidations which have to be probed against > the HW shadow PTEs. > >> It isn't that expensive, there is an extra driver lock/unlock as >> part of the lookup and possibly a f...

...rselves? > > > > Except for that the patch looks good to me: > > > > Reviewed-by: Christoph Hellwig <hch at lst.de> > > > > I think keeping the call to walk_page_range() makes sense. > Jason is hoping to be able to snapshot a range with & without vmas > and have the pfns[] filled with empty/valid entries as appropriate. > > I plan to repost my patch changing hmm_range_fault() to use > walk.test_walk which will remove the call to find_vma(). > Jason had some concerns about testing it so that's why I have > been working on s...

On Fri, Aug 23, 2019 at 03:17:52PM -0700, Ralph Campbell wrote: > Although hmm_range_fault() calls find_vma() to make sure that a vma exists > before calling walk_page_range(), hmm_vma_walk_hole() can still be called > with walk->vma == NULL if the start and end address are not contained > within the vma range. Should we convert to walk_vma_range instead? Or keep walk_page_range