All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: NeilBrown <neilb@suse.de>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 03/13] VFS: remove nameidata args from ->follow_link and ->put_link
Date: Mon, 16 Mar 2015 20:47:32 +0000	[thread overview]
Message-ID: <20150316204732.GB29656@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20150316044319.23648.2840.stgit@notabene.brown>

On Mon, Mar 16, 2015 at 03:43:19PM +1100, NeilBrown wrote:
> Now that current->nameidata is available, nd_set_link() and
> nd_get_link() can use that directly, so 'nd' doesn't need to
> be passed through ->follow_link and  ->put_link.

FWIW, I would rather pass nd_get_link(nd) to ->put_link() instead of nd.
Note that that's the only thing instances were ever using nd for; what's more,
that's the only thing nd_get_link() is ever used for outside of fs/namei.c,
so with that change it could become static in fs/namei.c.  After such change
we would have it used in
	* follow_link().  We have nd right there.
	* put_link().  Ditto.
	* generic_readlink().  Again, nd is right there (and we obviously
only need to call nd_get_link() once).
Hell, it can even become static inline...

>  	nd->last_type = LAST_BIND;
> -	*p = dentry->d_inode->i_op->follow_link(dentry, nd);
> +	*p = dentry->d_inode->i_op->follow_link(dentry, nd->flags);

I'm not sure if it's a good idea to expose all flags here - it's really
asking for somebody trying to be "smart" and acting differently depending
on what we are doing pathname resolution for/where in lookup we are/etc.
nd->flags & LOOKUP_RCU might be less tempting.

> @@ -4458,13 +4464,13 @@ int generic_readlink(struct dentry *dentry, char __user *buffer, int buflen)
>  	int res;
>  
>  	nd.depth = 0;
> -	cookie = dentry->d_inode->i_op->follow_link(dentry, &nd);
> +	cookie = dentry->d_inode->i_op->follow_link(dentry, nd.flags);

...(dentry, 0);  nd.flags is uninitialized, for pity sake...

  reply	other threads:[~2015-03-16 20:47 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-16  4:43 [PATCH 00/13] Support follow_link in RCU-walk. - V2 NeilBrown
2015-03-16  4:43 ` [PATCH 02/13] VFS: make all ->follow_link handlers aware for LOOKUP_RCU NeilBrown
2015-03-16  4:43 ` [PATCH 03/13] VFS: remove nameidata args from ->follow_link and ->put_link NeilBrown
2015-03-16 20:47   ` Al Viro [this message]
2015-03-16  4:43 ` [PATCH 01/13] VFS: replace {, total_}link_count in task_struct with pointer to nameidata NeilBrown
2015-03-16 19:46   ` Al Viro
2015-03-16  4:43 ` [PATCH 04/13] security/selinux: check for LOOKUP_RCU in _follow_link NeilBrown
2015-03-16 21:00   ` Al Viro
2015-03-20  4:39     ` NeilBrown
2015-03-20  5:12       ` Al Viro
2015-03-16  4:43 ` [PATCH 05/13] VFS/namei: use terminate_walk when symlink lookup fails NeilBrown
2015-03-16  4:43 ` [PATCH 12/13] XFS: allow follow_link to often succeed in RCU-walk NeilBrown
2015-03-16 22:37   ` Al Viro
2015-03-16  4:43 ` [PATCH 08/13] VFS/namei: enhance follow_link to support RCU-walk NeilBrown
2015-03-16  4:43 ` [PATCH 06/13] VFS/namei: new flag to support RCU symlinks: LOOKUP_LINK_RCU NeilBrown
2015-03-16 22:33   ` Al Viro
2015-03-17  0:59     ` Al Viro
2015-03-16  4:43 ` [PATCH 13/13] NFS: support LOOKUP_RCU in nfs_follow_link NeilBrown
2015-03-16  4:43 ` [PATCH 09/13] VFS/namei: enable RCU-walk when following symlinks NeilBrown
2015-03-16 22:44   ` Al Viro
2015-03-16  4:43 ` [PATCH 10/13] VFS/namei: handle LOOKUP_RCU in page_follow_link_light NeilBrown
2015-03-16 22:50   ` Al Viro
2015-03-19 22:38     ` NeilBrown
2015-03-19 23:46       ` Al Viro
2015-03-16  4:43 ` [PATCH 07/13] VFS/namei: abort RCU-walk on symlink if atime needs updating NeilBrown
2015-03-16  4:43 ` [PATCH 11/13] xfs: use RCU to free 'struct xfs_mount' NeilBrown
2015-03-16 19:14 ` [PATCH 00/13] Support follow_link in RCU-walk. - V2 Al Viro

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=20150316204732.GB29656@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=neilb@suse.de \
    /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.