Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp593183yba; Thu, 16 May 2019 06:05:11 -0700 (PDT) X-Google-Smtp-Source: APXvYqzw4uoT7GHU4UHh2gdGQWtWq7hoSxA4h/PFclYZuG4rO3/c6FGmo2m8g/khzKzt3Ox6qkz8 X-Received: by 2002:a17:902:765:: with SMTP id 92mr49153310pli.196.1558011911526; Thu, 16 May 2019 06:05:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1558011911; cv=none; d=google.com; s=arc-20160816; b=NhlEZwconQ9HRTbHz2hGOYyH04ndkikWYFabmdCbJ2yLHE5iS/cnM1P9YdpgnTmBWN yxeVzDJhwwYgH978ULVmuaTbI+M7IhriM6uSjVgw3EaOHmUHfDCrCkXOFhGkT/R0UjnF GQFUOs1AVMjPVOgu40tZ3Zm9SCyXyXC/QLzccLhrAo+bmICOkkIsK6VgT3xJ36/2WSND Tw8XPeW22gulbXiLPgQtbgsYYvJBjZl3Os2WKYQwoR97qcNxt6cZNjRP9HkTCQJaUAIJ sNXZ4cNRFOPo5nfSfYrp+lImFOiaV25nBiBAM6Cencq2t1HZQnV8Ty5bQX0bqskgb5ZE dQvg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=WNdy61vJT/6/APtY5tF6cpzhh5oF2Ja2UZFn9VPKnbI=; b=eXvN1hGhSesjOX6mFQSigUTPP9DuClfIA/tbHc9Bax+BzEFeOd508LlNH5hnJL8U3k eEKImpzvdHPEyvOt7xum81rc1oaEMVMcxRgFfjkP7Li2Q61UczD03hwGh4QoIrLZ2uzv MN2U3jKGpyWQRc5aLUbKb+oaoxgKGikbBxMBphQRstDHUYVWvN3abK+Pm0KI0ChaI+Mp yZbv8++TiBMhP3gWFDjyH1+L729tCD1L5GGDlxJK3ptG/F8lJmLEW/DmDbCGpZtUvhEu VVHE3narBBzChVkRXURQSFZ5Sd19OHY3dav2qlCq07uVCQUxEJP0eJFrW4T5EE/BuhTq vmHQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=virtuozzo.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 90si456992pla.323.2019.05.16.06.04.53; Thu, 16 May 2019 06:05:11 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=virtuozzo.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727496AbfEPNDE (ORCPT + 99 others); Thu, 16 May 2019 09:03:04 -0400 Received: from relay.sw.ru ([185.231.240.75]:51894 "EHLO relay.sw.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727469AbfEPNDD (ORCPT ); Thu, 16 May 2019 09:03:03 -0400 Received: from [172.16.25.169] by relay.sw.ru with esmtp (Exim 4.91) (envelope-from ) id 1hRG2D-0006j8-2v; Thu, 16 May 2019 16:02:57 +0300 Subject: Re: [PATCH RFC 0/5] mm: process_vm_mmap() -- syscall for duplication a process mapping To: Jann Horn Cc: Andrew Morton , Dan Williams , Michal Hocko , keith.busch@intel.com, "Kirill A . Shutemov" , pasha.tatashin@oracle.com, Alexander Duyck , ira.weiny@intel.com, Andrey Konovalov , arunks@codeaurora.org, Vlastimil Babka , Christoph Lameter , Rik van Riel , Kees Cook , hannes@cmpxchg.org, npiggin@gmail.com, Mathieu Desnoyers , shakeelb@google.com, Roman Gushchin , Andrea Arcangeli , Hugh Dickins , Jerome Glisse , Mel Gorman , daniel.m.jordan@oracle.com, kernel list , Linux-MM References: <155793276388.13922.18064660723547377633.stgit@localhost.localdomain> From: Kirill Tkhai Message-ID: <456c7367-0656-933b-986d-febdcc5ab98e@virtuozzo.com> Date: Thu, 16 May 2019 16:02:55 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Jann, On 15.05.2019 21:46, Jann Horn wrote: > On Wed, May 15, 2019 at 5:11 PM Kirill Tkhai wrote: >> This patchset adds a new syscall, which makes possible >> to clone a mapping from a process to another process. >> The syscall supplements the functionality provided >> by process_vm_writev() and process_vm_readv() syscalls, >> and it may be useful in many situation. >> >> For example, it allows to make a zero copy of data, >> when process_vm_writev() was previously used: > [...] >> This syscall may be used for page servers like in example >> above, for migration (I assume, even virtual machines may >> want something like this), for zero-copy desiring users >> of process_vm_writev() and process_vm_readv(), for debug >> purposes, etc. It requires the same permittions like >> existing proc_vm_xxx() syscalls have. > > Have you considered using userfaultfd instead? userfaultfd has > interfaces (UFFDIO_COPY and UFFDIO_ZERO) for directly shoving pages > into the VMAs of other processes. This works without the churn of > creating and merging VMAs all the time. userfaultfd is the interface > that was written to support virtual machine migration (and it supports > live migration, too). I know about userfaultfd, but it does solve the discussed problem. It allocates new pages to make UFFDIO_COPY (see mcopy_atomic_pte()), and it accumulates all the disadvantages, the example from [0/5] message has. Kirill