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=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 0CA34C43603 for ; Thu, 19 Dec 2019 10:35:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D2DA321D7D for ; Thu, 19 Dec 2019 10:35:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726873AbfLSKfc (ORCPT ); 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