[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120723090304.GF31729@ZenIV.linux.org.uk>
Date: Mon, 23 Jul 2012 10:03:04 +0100
From: Al Viro <viro@...IV.linux.org.uk>
To: Boaz Harrosh <bharrosh@...asas.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
Stephen Rothwell <sfr@...b.auug.org.au>,
Trond Myklebust <Trond.Myklebust@...app.com>
Subject: Re: [git pull] vfs.git; pile 1
On Mon, Jul 23, 2012 at 11:20:25AM +0300, Boaz Harrosh wrote:
> On 07/22/2012 11:20 PM, Al Viro wrote:
>
> > I think the least painful solution is this: I've created a new branch
> > (for-linus-2) in there, growing off the parent of merge in nfs.git.
> > I've put the fixup to kern_path_locked() there as a separate commit
> > + stuff that went in for-linus after that point.
> >
>
>
> Does this means that between "kern_path_locked() patch" and it's fixup
> the tree is not bisectable? or is it just an enhancement/simplification?
>
> Not having any opinion, just wants to know
It is bisectable, all right; lookup_one_len() is OK there (note that
places converted to kern_path_locked() used to use it before the
conversion. It's just that lookup_one_len() is an overkill - we
have already checked exec permissions on parent and we'd already
calculated the full qstr for last component - both length and hash.
All that is left to do is actual __lookup_hash()...
--
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