[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110216163951.GG22723@ZenIV.linux.org.uk>
Date: Wed, 16 Feb 2011 16:39:51 +0000
From: Al Viro <viro@...IV.linux.org.uk>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Eric Dumazet <eric.dumazet@...il.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
npiggin@...nel.dk
Subject: Re: Linux 2.6.38-rc5
On Wed, Feb 16, 2011 at 08:33:32AM -0800, Linus Torvalds wrote:
> Does it make tons of conceptual sense to pass in 'inode' to
> do_follow_link? No, it's clearly redundant information, which is the
> whole point of the BUG_ON(). But it does allow that extra shared
> sanity test, and we _could_ also then do
>
> - if (!IS_ERR(cookie) && path->dentry->d_inode->i_op->put_link)
> - path->dentry->d_inode->i_op->put_link(path->dentry,
> nd, cookie);
> + if (!IS_ERR(cookie) && inode->i_op->put_link)
> + inode->i_op->put_link(path->dentry, nd, cookie);
>
> since we've verified that 'inode' is 'path->dentry->d_inode', and all
> of those should be stable over all the calls (in the non-RCU case,
> which we are in).
>
> I dunno. I don't care _deeply_, but I do have to say that I much liked
> how you moved the
>
> if (nameidata_dentry_drop_rcu_maybe(nd, path->dentry))
> ..
>
> into do_follow_link(). I think it made it clearer that do_follow_link
> (and __do_follow_link()) aren't done with RCU.
OK, I can live with that. Consider me convinced, let's go with your variant.
Speaking of ugliness: Nick, why the _fuck_ have you reverted non-create case
in do_filp_open() to do_path_lookup()?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists