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=-8.4 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL 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 C18DFC5DF60 for ; Thu, 7 Nov 2019 08:55:39 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 83E8721D7B for ; Thu, 7 Nov 2019 08:55:39 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="k2Zi5ilU" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 83E8721D7B Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 17CE66B000A; Thu, 7 Nov 2019 03:55:39 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 12E416B000C; Thu, 7 Nov 2019 03:55:39 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 069FD6B000D; Thu, 7 Nov 2019 03:55:39 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0230.hostedemail.com [216.40.44.230]) by kanga.kvack.org (Postfix) with ESMTP id E48DB6B000A for ; Thu, 7 Nov 2019 03:55:38 -0500 (EST) Received: from smtpin20.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with SMTP id AF1A15DD0 for ; Thu, 7 Nov 2019 08:55:38 +0000 (UTC) X-FDA: 76128873156.20.chair58_8881366ce6211 X-HE-Tag: chair58_8881366ce6211 X-Filterd-Recvd-Size: 5341 Received: from mail-lf1-f68.google.com (mail-lf1-f68.google.com [209.85.167.68]) by imf50.hostedemail.com (Postfix) with ESMTP for ; Thu, 7 Nov 2019 08:55:37 +0000 (UTC) Received: by mail-lf1-f68.google.com with SMTP id m6so978279lfl.3 for ; Thu, 07 Nov 2019 00:55:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zWZb6GLCF2st+ZVn+OJmwleeG1odyNOnzVdWxMN71m4=; b=k2Zi5ilUpvfwvkE4Ppxa+x0nf4km4BOuvWm1ykPz7BHyrgqo9vEkTpio3e+6YeSAiA ksg0hvGFAxJJ5+A1qVHYbExIOTneSQo46Sclk8UiCKSz3NT2s4jWy4p2tAEvwQrmNNiU R1dMTOqkY/lBDgJo9yps5cz+dnI+fVkq6IK2r1jtC5lneKbhlws47UcUOwdRPKltMqm6 zij//x+VBfeyEyoCWdveF8tUyAQEZ/iEK//xFdiRYEFxUGp0LG7WkmOsphoK1smcLmLN NJv5g+5Rf59q8D3VZyo4H3tIiMq2sFCIea6ZVnCBi3GTqfgWNkPBXG3iEIDBsP1axhe2 e4hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zWZb6GLCF2st+ZVn+OJmwleeG1odyNOnzVdWxMN71m4=; b=fDJc6QvHYLBuSartirlC5TjrOoLMiNtLPfAX3waNyY7HUH+ibOu/heWtBxwjAv1J0r wV7fwVEoUkGUgxcZgslaxhmiPHRCzOEx/ODLqQ7/w8UXMSyd3wslFKaYmndR4gsF4okM 6Coz2NE3+qn3J7pK7Rd7e6w1Iu7s6N1xV9dcNHqkQPTo4Lo+FGw5dWP6XRjapB6P4b2A EzzF8DTBMhGWJaXvgldXIUnJcSB5gZrkweH9QCIP77RxB04sMKh1gcf8t+46Z+tExtci wExyq1LTsFszyLhtvebeMZnMWlCjDbIPXz9prV6iyjG/gZy2Cl74RXlS+RQTyy2FTBXc TTvA== X-Gm-Message-State: APjAAAW8A+XzVaSSpl0H7K6rCvP7JRu0It0dz5mFHWlTPWrt5/f7zCyk p8LbFhugRedR1llCr5LuJZePqxxqpdlwTTbhxWcK0w== X-Google-Smtp-Source: APXvYqwjmdL6xPlKTj58mFSrRkwb7zeLwRzSWb8Xgzdfaw5gPK5uHdRZEynEOzKUFWJ8jFmyiGAvxtKcJWxmRt9gblQ= X-Received: by 2002:a19:8582:: with SMTP id h124mr1571095lfd.64.1573116935696; Thu, 07 Nov 2019 00:55:35 -0800 (PST) MIME-Version: 1.0 References: <1572967777-8812-1-git-send-email-rppt@linux.ibm.com> <1572967777-8812-2-git-send-email-rppt@linux.ibm.com> <20191105162424.GH30717@redhat.com> <20191107083902.GB3247@linux.ibm.com> In-Reply-To: <20191107083902.GB3247@linux.ibm.com> From: Daniel Colascione Date: Thu, 7 Nov 2019 00:54:59 -0800 Message-ID: Subject: Re: [PATCH 1/1] userfaultfd: require CAP_SYS_PTRACE for UFFD_FEATURE_EVENT_FORK To: Mike Rapoport Cc: Andrea Arcangeli , Andy Lutomirski , linux-kernel , Andrew Morton , Jann Horn , Linus Torvalds , Lokesh Gidra , Nick Kralevich , Nosh Minwalla , Pavel Emelyanov , Tim Murray , Linux API , linux-mm Content-Type: text/plain; charset="UTF-8" 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 Thu, Nov 7, 2019 at 12:39 AM Mike Rapoport wrote: > On Tue, Nov 05, 2019 at 08:41:18AM -0800, Daniel Colascione wrote: > > On Tue, Nov 5, 2019 at 8:24 AM Andrea Arcangeli wrote: > > > The long term plan is to introduce UFFD_FEATURE_EVENT_FORK2 feature > > > flag that uses the ioctl to receive the child uffd, it'll consume more > > > CPU, but it wouldn't require the PTRACE privilege anymore. > > > > Why not just have callers retrieve FDs using recvmsg? This way, you > > retrieve the message packet and the file descriptor at the same time > > and you don't need any appreciable extra CPU use. > > I don't follow you here. Can you elaborate on how recvmsg would be used in > this case? Imagine an AF_UNIX SOCK_DGRAM socket. You call recvmsg(). You get a blob of regular data along with some ancillary data. The ancillary data may include some file descriptors or it may not. Isn't the UFFD message model the same thing? You'd call recvmsg() on a UFFD and get back a uffd_msg data structure. If that uffd_msg came with file descriptors, these descriptors would be in ancillary data. If you didn't reserve enough space for the message or enough space for its ancillary data, the recvmsg() call would fail cleanly with MSG_TRUNC or MSG_CTRUNC. The nice thing about using recvmsg() for this purpose is that there's tons of existing code for dealing with recvmsg()'s calling convention and its ancillary data. You can, for example, use recvmsg out of the box in a Python script. You could make an ioctl that also returned a data blob plus some optional file descriptors, but if recvmsg already does exactly that job and it's well-understood, why not just reuse the recvmsg interface? How practical is it to actually support recvmsg without being a socket? How hard would it be to just become a socket? I don't know. My point is only that *from a userspace API* point of view, recvmsg() seems ideal.