Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp1764326ybl; Thu, 19 Dec 2019 02:37:11 -0800 (PST) X-Google-Smtp-Source: APXvYqxwBLysbQrxEbaTePDSOWXE4IJwtTNAceN12HsbaA79Qid3yIPG741KQMvSk/TwdjF5/RTO X-Received: by 2002:a9d:5c84:: with SMTP id a4mr7546816oti.305.1576751831774; Thu, 19 Dec 2019 02:37:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1576751831; cv=none; d=google.com; s=arc-20160816; b=GqnQo9WWfPpERhvhe1v07whrNYGUZaHcBJ6HwyAJHD/ZaU2TB5HLp59XNDJwpnO8LZ vr+TM5mOujSDBVrtXYe3tNqTnCkNZ5SPqy+9xkaefebrJD9Pt3kPoN0v5n80DYgYFLyK 3/7674XPC0CfpjGd74uyKGrRHH73o+6B6dJJR17JF8wAcWk7c3TBtaotEcKTQwb1axDW Yp3mRvELJ2qOnMUzBS+5N/4YgyM16Y809g3jyOe8/6uDU5zwz9F1M8ML0PXPE3T0aQuY XRSZF/yiV24Zr5+O293gsvxVbZQeXsj7GSJAxZcPmJLZSOFYSWNzsmiOiL8dGTlUin+Z B5nw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=1kYJWAE3SjmOT9zBCzBE102BVXzaQiwCgIeDJWf9/nI=; b=zpiKBSZ8jjDiT/hRHYb5wjy4F1Dm+8fmu53b3VuxDAXE70Ewr9NqxSjUDL06haB7J/ tareK1G8pa8R+lR6qT14Tsi8/To8uRXNGkCr0JA5DZ2A6I4sdcqonXlcRluBmDUf5jLw beKWg+BRVuYC1qdU+g0ma7r6nngfQXRSxDe4T81OiOt8/vg/j+avowCkAvSl1A3m9N37 X4/QSOEOvaX6uOiZnGdCHQhI5doKmI9Ud03buQNDljI63njjSY2eSVZZsan7eMpbCy+A RCmJzlBvlzNxsXnpoa4WXlfPEAb+VnGKWcqOEO3rZl8UNznSY+5ChrZWWFmjVUC8AclY ZZdg== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r5si2848702oic.19.2019.12.19.02.37.00; Thu, 19 Dec 2019 02:37:11 -0800 (PST) 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726777AbfLSKfc (ORCPT + 99 others); Thu, 19 Dec 2019 05:35:32 -0500 Received: from youngberry.canonical.com ([91.189.89.112]:37547 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726692AbfLSKfb (ORCPT ); Thu, 19 Dec 2019 05:35:31 -0500 Received: from [79.140.121.60] (helo=wittgenstein) by youngberry.canonical.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1iht9T-00014D-C2; Thu, 19 Dec 2019 10:35:27 +0000 Date: Thu, 19 Dec 2019 11:35:26 +0100 From: Christian Brauner To: Arnd Bergmann , Oleg Nesterov , Florian Weimer Cc: Sargun Dhillon , "linux-kernel@vger.kernel.org" , Linux Containers , Linux API , Linux FS-devel Mailing List , Tycho Andersen , Jann Horn , Aleksa Sarai , Christian Brauner , Andy Lutomirski , Al Viro , gpascutto@mozilla.com, ealvarez@mozilla.com, Florian Weimer , jld@mozilla.com Subject: Re: [PATCH v4 2/5] pid: Add PIDFD_IOCTL_GETFD to fetch file descriptors from processes Message-ID: <20191219103525.yqb5f4pbd2dvztkb@wittgenstein> References: <20191218235459.GA17271@ircssh-2.c.rugged-nimbus-611.internal> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Dec 19, 2019 at 09:03:09AM +0100, Arnd Bergmann wrote: > On Thu, Dec 19, 2019 at 12:55 AM Sargun Dhillon wrote: > > > +#define PIDFD_IOCTL_GETFD _IOWR('p', 0xb0, __u32) > > This describes an ioctl command that reads and writes a __u32 variable > using a pointer passed as the argument, which doesn't match the > implementation: > > > +static long pidfd_getfd(struct pid *pid, u32 fd) > > +{ > ... > > + return retfd; > > This function passes an fd as the argument and returns a new > fd, so the command number would be > > #define PIDFD_IOCTL_GETFD _IO('p', 0xb0) > > While this implementation looks easy enough, and it is roughly what > I would do in case of a system call, I would recommend for an ioctl I guess this is the remaining question we should settle, i.e. what do we prefer. I still think that adding a new syscall for this seems a bit rich. On the other hand it seems that a lot more people agree that using a dedicated syscall instead of an ioctl is the correct way; especially when it touches core kernel functionality. I mean that was one of the takeaways from the pidfd API ioctl-vs-syscall discussion. A syscall is nicer especially for core-kernel code like this. So I guess the only way to find out is to try the syscall approach and either get yelled and switch to an ioctl() or have it accepted. What does everyone else think? Arnd, still in favor of a syscall I take it. Oleg, you had suggested a syscall too, right? Florian, any thoughts/worries on/about this from the glibc side? Christian