qemu-devel
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]