Received: by 10.213.65.68 with SMTP id h4csp2208483imn; Thu, 5 Apr 2018 10:48:01 -0700 (PDT) X-Google-Smtp-Source: AIpwx48csAtjmEDh13ie5EvHHWVPNdBZKR8LWFvYxwQB6xa1CN+a7Gdd5syNgJMXP1x9tc/Jp4IJ X-Received: by 10.101.101.136 with SMTP id u8mr7872917pgv.333.1522950401443; Thu, 05 Apr 2018 10:46:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522950401; cv=none; d=google.com; s=arc-20160816; b=gMh4ibsi/JK6rNMDqnEoQ3H93lGKu5RC25/QleO+wySDSgGnqRjbV4FMXwwhJWp9ip 34zznj2OrknapO4izii9VMJgit8HID59YRa27qQ32cRaVogVs8seGkmTs+Jf8+5vZiui SPkiehDZ3dCD+lME1seT4avmNT257H93B+Oa4AGdkN6gUcHgZmV8zOjs6J0yOjyEFY+J 9ZW1goSfMsN4OfDX0M8Nj6/Ja8UUYcBnWN3LbUZ0tsR5u+GxYw9aoSACneMeOfGqsXX9 wbaR3M0FRgnJSbCDVScyt2E5qvec7j2INHyoGr0lXzuMwuq9y238pxIaQ5h2l25ndZVl wkNg== 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:date:from:arc-authentication-results; bh=pN/yMQlqN5bqEHFDJei3u+aTZINtIq+qmznUSHNCRIs=; b=U0FsIq3a7y1Hc4WKRIMbQEamgiZ1EgTr97S4Y8yr+zU7MkVMXG1aQ5LEypc0QSOQGx 8UOUHFdHJM09WXhCi7R4OU1s5Ira0VTQ31AuZmapPcfqisezR5kDruQNXEZyiSdvISpv DO7cKc7OXH56EcZAvBs+AESnM/Nsv8iDZ3VRdA4abh9bTjvWEJ/7T3pGpHF/lsg8Kb5t 3oCpotG1xb9tEs4pWN2oFAcC1Gbm8j/3NSRKI28FuFTno5Hx81kyazjOmeWrh78tba0T NsvIH2+yVzyaoIDtfOtR5HVDoseK3yv7s9ouKOXOzETlVwwF9d7GATJJeadWOIYU0IBr bvjg== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=canonical.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w184si5694451pgb.661.2018.04.05.10.46.27; Thu, 05 Apr 2018 10:46:41 -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; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=canonical.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751534AbeDERpU (ORCPT + 99 others); Thu, 5 Apr 2018 13:45:20 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:55073 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750786AbeDERpS (ORCPT ); Thu, 5 Apr 2018 13:45:18 -0400 Received: from mail-wr0-f199.google.com ([209.85.128.199]) by youngberry.canonical.com with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1f48wn-0008Ge-HG for linux-kernel@vger.kernel.org; Thu, 05 Apr 2018 17:45:17 +0000 Received: by mail-wr0-f199.google.com with SMTP id u5so5777384wrc.23 for ; Thu, 05 Apr 2018 10:45:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=pN/yMQlqN5bqEHFDJei3u+aTZINtIq+qmznUSHNCRIs=; b=qbKQLHHst2E5MZ8b83UiTPWBkx1jQJQiNXImcyZNUl/rPk8/tOPmqlBblePhW6nOa0 JzAJ7iiea9XPD1BzmPbn5WLLArCLO7vsYDWkIJPwZffhcfHc75iIwXYKfAZ4Ofpd9jt7 oBsJs5IGknbpwhMXd0XucuW0nteSVk7hwTyf+11yfkP7zfWr6loYZhtdSK7cQgdU4M9n yeOyPG46G5VizB+/d8/6QfPtIgAgT2d2a1tAU02v8tMqQiBwCAW8w4GuUHUfSPwfw7X3 ED6USj92UhGpJnngLLM9GPhVfrTHc3eI9YqUWamtqGDFkM+onT6vRq5zO0Dvi6d4s6nb kC3A== X-Gm-Message-State: AElRT7G39DWWtyeLtejxdpqP/T8M4mKvOkbbCmQkhmHyJZqEg3ZMMLIn yhGj3slhR9D+8MKJtjSqnmsAA/FR5WKGEG4VQ3lajo29kPvC3ubvXz/xs1M7j7X60oegskTvQpu xyjS7pfjEmxr9VTiLfBAykP0VwI/m2UHPpOWbtMQIMw== X-Received: by 10.223.225.136 with SMTP id k8mr16484587wri.148.1522950316835; Thu, 05 Apr 2018 10:45:16 -0700 (PDT) X-Received: by 10.223.225.136 with SMTP id k8mr16484574wri.148.1522950316592; Thu, 05 Apr 2018 10:45:16 -0700 (PDT) Received: from gmail.com ([2a02:8070:8895:9700:79fe:21e8:31e9:aa8b]) by smtp.gmail.com with ESMTPSA id i52sm13278688wra.82.2018.04.05.10.45.15 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 05 Apr 2018 10:45:15 -0700 (PDT) From: Christian Brauner X-Google-Original-From: Christian Brauner Date: Thu, 5 Apr 2018 19:45:15 +0200 To: Linus Torvalds Cc: Al Viro , "Eric W. Biederman" , Linux Kernel Mailing List Subject: Re: [PATCH 0/3 RESEND] namei: add follow_up_bind() Message-ID: <20180405174455.GA27462@gmail.com> References: <20180405105103.21572-1-christian.brauner@ubuntu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 05, 2018 at 09:28:56AM -0700, Linus Torvalds wrote: > On Thu, Apr 5, 2018 at 3:51 AM, Christian Brauner > wrote: > > > > This series adds: > > - follow_up_bind() to namei.{c,h} > > - switches fs/nfsd/vfs.c:follow_to_parent() to use follow_up_bind() > > - switches fs/devpts/inode.c:devpts_mntget() to use follow_up_bind() > > Hmm. Seems fair enough to me, although I wonder how much this really > helps. It does get rid of a duplicate code pattern, but: > > 4 files changed, 14 insertions(+), 5 deletions(-) > > and while some of that is just the new comment, some of it is just "overhead". Fwiw, it does get read of these while loops in two places but I personally see the biggest value in making it obvious what bind-mount resolution means. > > It's also a bit odd how the new helper is marked "inline", but nobody > will inline it because it's not actually in the header file or any of > the isers in the same C file. So instead, it has to be exported. I > wonder if it should just be a trivial inline in ? Maybe > it originally was, and that's where the inline came from, and then > Christian decided to make it be by the regular "follow_up()" instead? I head it inline first but it would have required to forward declare struct vfsmount in the head and I wasn't sure if that was going to fly. But I explicitly left the inline in there because I was following user_path_create() ([1], [2]) which does the same. But if that's an issue I can make it static inline in the header like I had, forward declare struct vfsmount and remove the unnecessary inline from user_path_create() in a separate patch unless there's a specific reason to leave it in there. [1]: https://elixir.bootlin.com/linux/latest/source/include/linux/namei.h#L79 [2]: https://elixir.bootlin.com/linux/latest/source/fs/namei.c#L3680 > > But with all that said, I certainly don't *mind* the patch series. Cool. Thanks! Christian > > Al, I'm leaving this up to you, and expect to get it from your vfs > tree eventually. Or not. > > Linus