From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pavel Emelyanov Subject: Re: [PATCH 19/21] userfaultfd: remap_pages: UFFDIO_REMAP preparation Date: Thu, 5 Mar 2015 21:01:22 +0300 Message-ID: <54F899F2.6000904@parallels.com> References: <1425575884-2574-1-git-send-email-aarcange@redhat.com> <1425575884-2574-20-git-send-email-aarcange@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1425575884-2574-20-git-send-email-aarcange@redhat.com> Sender: owner-linux-mm@kvack.org To: Andrea Arcangeli , qemu-devel@nongnu.org, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-api@vger.kernel.org, Android Kernel Team Cc: "Kirill A. Shutemov" , Sanidhya Kashyap , zhang.zhanghailiang@huawei.com, Linus Torvalds , Andres Lagar-Cavilla , Dave Hansen , Paolo Bonzini , Rik van Riel , Mel Gorman , Andy Lutomirski , Andrew Morton , Sasha Levin , Hugh Dickins , Peter Feiner , "Dr. David Alan Gilbert" , Christopher Covington , Johannes Weiner , Robert Love , Dmitry Adamushko , Neil Brown , Mike Hommey , Taras Glek , Jan Kara , KOSAKI Motohiro List-Id: linux-api@vger.kernel.org > +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 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pavel Emelyanov Subject: Re: [PATCH 19/21] userfaultfd: remap_pages: UFFDIO_REMAP preparation Date: Thu, 5 Mar 2015 21:01:22 +0300 Message-ID: <54F899F2.6000904@parallels.com> References: <1425575884-2574-1-git-send-email-aarcange@redhat.com> <1425575884-2574-20-git-send-email-aarcange@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: "Kirill A. Shutemov" , Sanidhya Kashyap , , Linus Torvalds , Andres Lagar-Cavilla , Dave Hansen , Paolo Bonzini , Rik van Riel , Mel Gorman , Andy Lutomirski , Andrew Morton , Sasha Levin , Hugh Dickins , Peter Feiner , "Dr. David Alan Gilbert" , Christopher Covington , Johannes Weiner , Robert Love , Dmitry Adamushko , Neil Brown , Mike Hommey , Taras Glek , Jan Kara , KOSAKI Motohiro , , , , , , Android Kernel Team Return-path: In-Reply-To: <1425575884-2574-20-git-send-email-aarcange@redhat.com> Sender: owner-linux-mm@kvack.org List-Id: kvm.vger.kernel.org > +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 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yh0-f49.google.com (mail-yh0-f49.google.com [209.85.213.49]) by kanga.kvack.org (Postfix) with ESMTP id 254BA6B0099 for ; Thu, 5 Mar 2015 13:01:46 -0500 (EST) Received: by yhoa41 with SMTP id a41so26563571yho.9 for ; Thu, 05 Mar 2015 10:01:45 -0800 (PST) Received: from mx2.parallels.com (mx2.parallels.com. [199.115.105.18]) by mx.google.com with ESMTPS id f188si4098123ykd.88.2015.03.05.10.01.44 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Mar 2015 10:01:44 -0800 (PST) Message-ID: <54F899F2.6000904@parallels.com> Date: Thu, 5 Mar 2015 21:01:22 +0300 From: Pavel Emelyanov MIME-Version: 1.0 Subject: Re: [PATCH 19/21] userfaultfd: remap_pages: UFFDIO_REMAP preparation References: <1425575884-2574-1-git-send-email-aarcange@redhat.com> <1425575884-2574-20-git-send-email-aarcange@redhat.com> In-Reply-To: <1425575884-2574-20-git-send-email-aarcange@redhat.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Andrea Arcangeli , qemu-devel@nongnu.org, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-api@vger.kernel.org, Android Kernel Team Cc: "Kirill A. Shutemov" , Sanidhya Kashyap , zhang.zhanghailiang@huawei.com, Linus Torvalds , Andres Lagar-Cavilla , Dave Hansen , Paolo Bonzini , Rik van Riel , Mel Gorman , Andy Lutomirski , Andrew Morton , Sasha Levin , Hugh Dickins , Peter Feiner , "Dr. David Alan Gilbert" , Christopher Covington , Johannes Weiner , Robert Love , Dmitry Adamushko , Neil Brown , Mike Hommey , Taras Glek , Jan Kara , KOSAKI Motohiro , Michel Lespinasse , Minchan Kim , Keith Packard , "Huangpeng (Peter)" , Anthony Liguori , Stefan Hajnoczi , Wenchao Xia , Andrew Jones , Juan Quintela > +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 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758557AbbCESBz (ORCPT ); Thu, 5 Mar 2015 13:01:55 -0500 Received: from mx2.parallels.com ([199.115.105.18]:56373 "EHLO mx2.parallels.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753881AbbCESBx (ORCPT ); Thu, 5 Mar 2015 13:01:53 -0500 Message-ID: <54F899F2.6000904@parallels.com> Date: Thu, 5 Mar 2015 21:01:22 +0300 From: Pavel Emelyanov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Andrea Arcangeli , , , , , , Android Kernel Team CC: "Kirill A. Shutemov" , Sanidhya Kashyap , , Linus Torvalds , Andres Lagar-Cavilla , Dave Hansen , Paolo Bonzini , Rik van Riel , Mel Gorman , Andy Lutomirski , Andrew Morton , Sasha Levin , Hugh Dickins , Peter Feiner , "Dr. David Alan Gilbert" , Christopher Covington , Johannes Weiner , Robert Love , Dmitry Adamushko , Neil Brown , Mike Hommey , Taras Glek , Jan Kara , KOSAKI Motohiro , Michel Lespinasse , Minchan Kim , Keith Packard , "Huangpeng (Peter)" , Anthony Liguori , Stefan Hajnoczi , Wenchao Xia , Andrew Jones , Juan Quintela Subject: Re: [PATCH 19/21] userfaultfd: remap_pages: UFFDIO_REMAP preparation References: <1425575884-2574-1-git-send-email-aarcange@redhat.com> <1425575884-2574-20-git-send-email-aarcange@redhat.com> In-Reply-To: <1425575884-2574-20-git-send-email-aarcange@redhat.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [89.169.95.100] X-ClientProxiedBy: US-EXCH.sw.swsoft.com (10.255.249.47) To US-EXCH.sw.swsoft.com (10.255.249.47) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > +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 From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53053) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YTa5w-0004vP-4f for qemu-devel@nongnu.org; Thu, 05 Mar 2015 13:02:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YTa5s-0008Og-PT for qemu-devel@nongnu.org; Thu, 05 Mar 2015 13:02:00 -0500 Received: from mx2.parallels.com ([199.115.105.18]:60000) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YTa5s-0008OU-Jx for qemu-devel@nongnu.org; Thu, 05 Mar 2015 13:01:56 -0500 Message-ID: <54F899F2.6000904@parallels.com> Date: Thu, 5 Mar 2015 21:01:22 +0300 From: Pavel Emelyanov MIME-Version: 1.0 References: <1425575884-2574-1-git-send-email-aarcange@redhat.com> <1425575884-2574-20-git-send-email-aarcange@redhat.com> In-Reply-To: <1425575884-2574-20-git-send-email-aarcange@redhat.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 19/21] userfaultfd: remap_pages: UFFDIO_REMAP preparation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andrea Arcangeli , qemu-devel@nongnu.org, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-api@vger.kernel.org, Android Kernel Team Cc: Robert Love , Dave Hansen , Jan Kara , Neil Brown , Stefan Hajnoczi , Andrew Jones , Sanidhya Kashyap , KOSAKI Motohiro , Michel Lespinasse , Taras Glek , zhang.zhanghailiang@huawei.com, Juan Quintela , Hugh Dickins , Mel Gorman , Sasha Levin , "Dr. David Alan Gilbert" , "Huangpeng (Peter)" , Andres Lagar-Cavilla , Christopher Covington , Anthony Liguori , Paolo Bonzini , "Kirill A. Shutemov" , Keith Packard , Wenchao Xia , Andy Lutomirski , Minchan Kim , Dmitry Adamushko , Johannes Weiner , Mike Hommey , Andrew Morton , Linus Torvalds , Peter Feiner > +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