[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 19/21] userfaultfd: remap_pages: UFFDIO_REMAP pr
From: |
Pavel Emelyanov |
Subject: |
Re: [Qemu-devel] [PATCH 19/21] userfaultfd: remap_pages: UFFDIO_REMAP preparation |
Date: |
Thu, 5 Mar 2015 21:01:22 +0300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 |
> +ssize_t remap_pages(struct mm_struct *dst_mm, struct mm_struct *src_mm,
> + unsigned long dst_start, unsigned long src_start,
> + unsigned long len, __u64 mode)
> +{
> + struct vm_area_struct *src_vma, *dst_vma;
> + long err = -EINVAL;
> + pmd_t *src_pmd, *dst_pmd;
> + pte_t *src_pte, *dst_pte;
> + spinlock_t *dst_ptl, *src_ptl;
> + unsigned long src_addr, dst_addr;
> + int thp_aligned = -1;
> + ssize_t moved = 0;
> +
> + /*
> + * Sanitize the command parameters:
> + */
> + BUG_ON(src_start & ~PAGE_MASK);
> + BUG_ON(dst_start & ~PAGE_MASK);
> + BUG_ON(len & ~PAGE_MASK);
> +
> + /* Does the address range wrap, or is the span zero-sized? */
> + BUG_ON(src_start + len <= src_start);
> + BUG_ON(dst_start + len <= dst_start);
> +
> + /*
> + * Because these are read sempahores there's no risk of lock
> + * inversion.
> + */
> + down_read(&dst_mm->mmap_sem);
> + if (dst_mm != src_mm)
> + down_read(&src_mm->mmap_sem);
> +
> + /*
> + * Make sure the vma is not shared, that the src and dst remap
> + * ranges are both valid and fully within a single existing
> + * vma.
> + */
> + src_vma = find_vma(src_mm, src_start);
> + if (!src_vma || (src_vma->vm_flags & VM_SHARED))
> + goto out;
> + if (src_start < src_vma->vm_start ||
> + src_start + len > src_vma->vm_end)
> + goto out;
> +
> + dst_vma = find_vma(dst_mm, dst_start);
> + if (!dst_vma || (dst_vma->vm_flags & VM_SHARED))
> + goto out;
I again have a concern about the case when one task monitors the VM of the
other one. If the target task (owning the mm) unmaps a VMA then the monitor
task (holding and operating on the ufd) will get plain EINVAL on UFFDIO_REMAP
request. This is not fatal, but still inconvenient as it will be hard to
find out the reason for failure -- dst VMA is removed and the monitor should
just drop the respective pages with data, or some other error has occurred
and some other actions should be taken.
Thanks,
Pavel
- [Qemu-devel] [PATCH 20/21] userfaultfd: UFFDIO_REMAP, (continued)
- [Qemu-devel] [PATCH 20/21] userfaultfd: UFFDIO_REMAP, Andrea Arcangeli, 2015/03/05
- [Qemu-devel] [PATCH 07/21] userfaultfd: call handle_userfault() for userfaultfd_missing() faults, Andrea Arcangeli, 2015/03/05
- [Qemu-devel] [PATCH 10/21] userfaultfd: add new syscall to provide memory externalization, Andrea Arcangeli, 2015/03/05
- [Qemu-devel] [PATCH 21/21] userfaultfd: add userfaultfd_wp mm helpers, Andrea Arcangeli, 2015/03/05
- [Qemu-devel] [PATCH 19/21] userfaultfd: remap_pages: UFFDIO_REMAP preparation, Andrea Arcangeli, 2015/03/05
- Re: [Qemu-devel] [PATCH 19/21] userfaultfd: remap_pages: UFFDIO_REMAP preparation,
Pavel Emelyanov <=
- [Qemu-devel] [PATCH 04/21] userfaultfd: linux/userfaultfd_k.h, Andrea Arcangeli, 2015/03/05
- [Qemu-devel] [PATCH 14/21] userfaultfd: mcopy_atomic|mfill_zeropage: UFFDIO_COPY|UFFDIO_ZEROPAGE preparation, Andrea Arcangeli, 2015/03/05
- [Qemu-devel] [PATCH 03/21] userfaultfd: uAPI, Andrea Arcangeli, 2015/03/05
- [Qemu-devel] [PATCH 05/21] userfaultfd: add vm_userfaultfd_ctx to the vm_area_struct, Andrea Arcangeli, 2015/03/05
- Re: [Qemu-devel] [PATCH 00/21] RFC: userfaultfd v3, Pavel Emelyanov, 2015/03/05
- [Qemu-devel] [PATCH 09/21] userfaultfd: prevent khugepaged to merge if userfaultfd is armed, Andrea Arcangeli, 2015/03/05
- [Qemu-devel] [PATCH 18/21] userfaultfd: UFFDIO_REMAP uABI, Andrea Arcangeli, 2015/03/05