Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp1436810ybi; Sat, 27 Jul 2019 09:37:32 -0700 (PDT) X-Google-Smtp-Source: APXvYqyRlhYVNZBb2VbwznSCn1G3+UalLmEQYzbi/tr3LhmhRdOLkQr+9w3/MkL0TtrvAZCOUrfb X-Received: by 2002:a65:404d:: with SMTP id h13mr94618516pgp.71.1564245452234; Sat, 27 Jul 2019 09:37:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1564245452; cv=none; d=google.com; s=arc-20160816; b=sBIJ9IZrLJ8a2oeSiBQjBF2sEVYQ9ylBgLeRmWj7KpJ7KTbrDDMNj/kxhGUc6ITcVN 5E9sZNfHZ5qaV296oEt+C5rmlO/SoRwtxuLV2GUqEKQcmvuE70N/6WhSiTvkYNW7U5nV BiUqabnfnm/OVVg5BGe4DePSat00oqsyUU911BI+M9c5iPHSk8RUYeeQCaVQLR+ozsFx ijzRlT4jUl9jVS0jd14/4rEiEMZrm8QPTtZgX291lzk1W2nJraNqgI3GcbtlUWDa0DTx mRwoMz0ASZ0TUSUOgIXjkam6UQxon5DrYpd3bzi+X3r5+CE1Z0t+S//Wke1mMTnbcnmI jnMg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=SMt3Dip69HxsJytg4yVDJuHJalu5ybWoDVCuTko6OO4=; b=S0H8+fpNLVUmJflHr7dnBS5CZWQFx6a2n/jv8umGfgaF5t3yrz3pfPWJko+zAfYC4i qGheRQSeE6OOB47HQIXBNp+iijk6j2KogWUNV+A1IGcFCrLtOapX/Hlfu1hV4m6aMYLV m/Ax4bDRCqTaJYHoYvWH00c91QDtmm2NMeJ9Km4BfByZitvbvuDFyR8bacH3pTPuaOK2 VlX2rDGzfreFy64c/NG06Giav5ImgxRw9t85dz/FMEnBmZLmtNzJyXaBO0KZX9kK0XgY Mjmw05CzxYYo4SUW38WUqnUUGuTQV2HgYxHnkUA0wQD0Z0HJ/7jzC7NTOx1QdKhlj0Ag BOug== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b="MJy3/ok5"; 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 v8si21871314plp.179.2019.07.27.09.37.17; Sat, 27 Jul 2019 09:37:32 -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; dkim=pass header.i=@linux-foundation.org header.s=google header.b="MJy3/ok5"; 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 S2387870AbfG0QfZ (ORCPT + 99 others); Sat, 27 Jul 2019 12:35:25 -0400 Received: from mail-lj1-f193.google.com ([209.85.208.193]:37873 "EHLO mail-lj1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728856AbfG0QfT (ORCPT ); Sat, 27 Jul 2019 12:35:19 -0400 Received: by mail-lj1-f193.google.com with SMTP id z28so126937ljn.4 for ; Sat, 27 Jul 2019 09:35:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SMt3Dip69HxsJytg4yVDJuHJalu5ybWoDVCuTko6OO4=; b=MJy3/ok5XyvWk6FJ4PplvzCbdcjfBIZF7gqdtNFDi1l2KLQms1yg8a7ubS4VlAHghm D82xRbcnUsbnTpdNRZOfJCtPBnQRdKjbfsWmPIAbuQOo94y8QSXmA56K1Wq/UT1daQ76 PplvjHeA4gcbYSESZq21nUXUjjmdRe1JiBYvM= 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=SMt3Dip69HxsJytg4yVDJuHJalu5ybWoDVCuTko6OO4=; b=D5b5jFFiQcfYR9qYJzqfsCD/ex1wnTZn225Jnu9PSAtnJy8HPGkWYfQmZ6s9kQRg05 cAeqk7fq1iIK948PcdARqdoZxRJ5xK0QbJHNFpJScrIojYEiWV0Lyawoku11SsGZ6MuA JYJ6NXzloxqBCfiskX7DOpg3ADyqMtK6o/1FQDM9kxZ5Dov8fxzAjIaTAgtVQnTEpTuy 5WKzHc12QMb6KIXR7Kpc/xEeqXKnLiQMTzntKvjVHAI1PRh4f4x25Jc+ZKqP7JulvEOh sTM9KWBJljS9Quk2xVQKJu5nWQ9d7EaKBySAPW4MIk7stNrRUbx2Ofu5rBDKlY4OCM9b g69A== X-Gm-Message-State: APjAAAWZ36X0WO18zjZpk0pfQgab7dFige4fyqHhKsg1oITxG7NBzk1N w42KBE+cgX9zk1q++7DzqeZeRfr26lk= X-Received: by 2002:a2e:5b0f:: with SMTP id p15mr51173440ljb.82.1564245316981; Sat, 27 Jul 2019 09:35:16 -0700 (PDT) Received: from mail-lj1-f169.google.com (mail-lj1-f169.google.com. [209.85.208.169]) by smtp.gmail.com with ESMTPSA id j14sm11218296ljc.67.2019.07.27.09.35.16 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Sat, 27 Jul 2019 09:35:16 -0700 (PDT) Received: by mail-lj1-f169.google.com with SMTP id m8so20780147lji.7 for ; Sat, 27 Jul 2019 09:35:16 -0700 (PDT) X-Received: by 2002:a2e:a0cf:: with SMTP id f15mr31325995ljm.180.1564244935984; Sat, 27 Jul 2019 09:28:55 -0700 (PDT) MIME-Version: 1.0 References: <20190727085201.11743-1-christian@brauner.io> <20190727085201.11743-2-christian@brauner.io> In-Reply-To: <20190727085201.11743-2-christian@brauner.io> From: Linus Torvalds Date: Sat, 27 Jul 2019 09:28:40 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 1/2] pidfd: add P_PIDFD to waitid() To: Christian Brauner Cc: Linux List Kernel Mailing , Oleg Nesterov , Arnd Bergmann , "Eric W. Biederman" , Kees Cook , Joel Fernandes , Thomas Gleixner , Tejun Heo , David Howells , Jann Horn , Andrew Lutomirski , Andrew Morton , Aleksa Sarai , Al Viro , Android Kernel Team Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Sorry to keep pestering about the patch series, but with the addition of P_PIDFD, I react once again.. On Sat, Jul 27, 2019 at 1:53 AM Christian Brauner wrote: > > --- a/kernel/exit.c > +++ b/kernel/exit.c > @@ -1555,6 +1555,7 @@ static long do_wait(struct wait_opts *wo) > static long kernel_waitid(int which, pid_t upid, struct waitid_info *infop, > int options, struct rusage *ru) > { > + struct fd f; Please don't do 'struct fd' at this level. That results in this ugly code later: > - put_pid(pid); > + if (which == P_PIDFD) > + fdput(f); > + else > + put_pid(pid); which just looks nasty. Instead, do all the 'file descriptor to pid' games here: > + case P_PIDFD: > + type = PIDTYPE_PID; > + if (upid < 0) > + return -EINVAL; > + > + f = fdget(upid); > + if (!f.file) > + return -EBADF; > + > + pid = pidfd_pid(f.file); > + if (IS_ERR(pid)) { > + fdput(f); > + return PTR_ERR(pid); > + } > break; and make thus just do something like pid = get_pid_from_fd(upid); if (IS_ERR(pid)) return PTR_ERR(pid); and now do that "fd to pid" in that helper function, and get the reference to 'struct pid *' there instead. Which you can actually do efficiently and lightly without even getting a ref to the 'struct file'. Something like struct pid *fd_to_pid(unsigned int fd) { struct fd f; struct pid *pid; f = fdget(fd); if (!f.file) return ERR_PTR(-EBADF); pid = pidfd_pid(f.file); if (!IS_ERR(pid)) get_pid(pid); fdput(f); return pid; } is the stupid and straightforward thing, but if you want to be *clever* you can actually avoid getting a reference to the 'struct file *" entirely, and do the fd->pid lookup under rcu_read_lock() instead. It's slightly more complex, but it avoids the fdget/fdput reference count games entirely. And then all that kernel_waitid() ever worries about is "struct pid *", and the ending goes back to just that simple put_pid(pid); return ret; instead. This was kind of my point of doing all the "find_get_pid()" games in the "switch()" statement - the different cases have different ways to look up what the "struct pid *" pointer should be, but they should all just look up a pid pointer, and then nothing else needs to care about 'type' any more. See? Hmm? Linus