From: Christian Brauner <christian.brauner@canonical.com>
To: Linus Torvalds <torvalds@linux-foundation.org>,
Al Viro <viro@zeniv.linux.org.uk>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/3 RESEND] namei: add follow_up_bind()
Date: Fri, 6 Apr 2018 14:47:12 +0200 [thread overview]
Message-ID: <20180406124711.GA9263@gmail.com> (raw)
In-Reply-To: <20180405174455.GA27462@gmail.com>
On Thu, Apr 05, 2018 at 07:45:15PM +0200, Christian Brauner wrote:
> On Thu, Apr 05, 2018 at 09:28:56AM -0700, Linus Torvalds wrote:
> > On Thu, Apr 5, 2018 at 3:51 AM, Christian Brauner
> > <christian.brauner@ubuntu.com> 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 <linux/namei.h>? 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
In case that wasn't clear from the previous message: I'd wait for a go
ahead on this if that's ok.
Christian
>
> >
> > 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
prev parent reply other threads:[~2018-04-06 12:47 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-05 10:51 [PATCH 0/3 RESEND] namei: add follow_up_bind() Christian Brauner
2018-04-05 10:51 ` [PATCH 1/3 " Christian Brauner
2018-04-05 10:51 ` [PATCH 2/3 RESEND] devpts: use follow_up_bind() helper Christian Brauner
2018-04-05 10:51 ` [PATCH 3/3 RESEND] nfsd: " Christian Brauner
2018-04-05 16:28 ` [PATCH 0/3 RESEND] namei: add follow_up_bind() Linus Torvalds
2018-04-05 17:45 ` Christian Brauner
2018-04-06 12:47 ` Christian Brauner [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180406124711.GA9263@gmail.com \
--to=christian.brauner@canonical.com \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.