From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CF3B7C43461 for ; Mon, 7 Sep 2020 15:05:51 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4F5E92078E for ; Mon, 7 Sep 2020 15:05:51 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4F5E92078E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ubuntu.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id D7FEE6B0003; Mon, 7 Sep 2020 11:05:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D2FE26B0037; Mon, 7 Sep 2020 11:05:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BF7856B0055; Mon, 7 Sep 2020 11:05:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0169.hostedemail.com [216.40.44.169]) by kanga.kvack.org (Postfix) with ESMTP id A9F3F6B0003 for ; Mon, 7 Sep 2020 11:05:50 -0400 (EDT) Received: from smtpin09.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 6299933CD for ; Mon, 7 Sep 2020 15:05:50 +0000 (UTC) X-FDA: 77236590060.09.frame88_0b0d450270cd Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin09.hostedemail.com (Postfix) with ESMTP id 398E2180AD817 for ; Mon, 7 Sep 2020 15:05:50 +0000 (UTC) X-HE-Tag: frame88_0b0d450270cd X-Filterd-Recvd-Size: 2716 Received: from youngberry.canonical.com (youngberry.canonical.com [91.189.89.112]) by imf31.hostedemail.com (Postfix) with ESMTP for ; Mon, 7 Sep 2020 15:05:49 +0000 (UTC) Received: from ip5f5af70b.dynamic.kabel-deutschland.de ([95.90.247.11] helo=wittgenstein) by youngberry.canonical.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1kFIiK-0004KC-Bk; Mon, 07 Sep 2020 15:05:48 +0000 Date: Mon, 7 Sep 2020 17:05:47 +0200 From: Christian Brauner To: Adalbert =?utf-8?B?TGF6xINy?= Cc: linux-mm@kvack.org, linux-api@vger.kernel.org, Andrew Morton , Alexander Graf , Stefan Hajnoczi , Jerome Glisse , Paolo Bonzini , Mihai =?utf-8?B?RG9uyJt1?= , Mircea Cirjaliu , Andy Lutomirski , Arnd Bergmann , Sargun Dhillon , Aleksa Sarai , Oleg Nesterov , Jann Horn , Kees Cook , Matthew Wilcox Subject: Re: [RESEND RFC PATCH 0/5] Remote mapping Message-ID: <20200907150547.hst4luvrpntdb3lr@wittgenstein> References: <20200904113116.20648-1-alazar@bitdefender.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200904113116.20648-1-alazar@bitdefender.com> X-Rspamd-Queue-Id: 398E2180AD817 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam04 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, Sep 04, 2020 at 02:31:11PM +0300, Adalbert Laz=C4=83r wrote: > This patchset adds support for the remote mapping feature. > Remote mapping, as its name suggests, is a means for transparent and > zero-copy access of a remote process' address space. > access of a remote process' address space. >=20 > The feature was designed according to a specification suggested by > Paolo Bonzini: > >> The proposed API is a new pidfd system call, through which the paren= t > >> can map portions of its virtual address space into a file descriptor > >> and then pass that file descriptor to a child. > >> > >> This should be: > >> > >> - upstreamable, pidfd is the new cool thing and we could sell it as = a > >> better way to do PTRACE_{PEEK,POKE}DATA In all honesty, that sentence made me a bit uneasy as it reads like this is implemented on top of pidfds because it makes it more likely to go upstream not because it is the right design. To be clear, I'm not implying any sort of malicious intent on your part but I would suggest to phrase this a little better. :)