On Sat, 1 Aug 2015, Linus Torvalds wrote:
> On Sat, Aug 1, 2015 at 9:06 PM, Hugh Dickins wrote:
> >
> > (I don't actually understand why the clearing of DCACHE_ENTRY_TYPE in
> > dentry_iput() is not of continuing concern; but don't worry, there's
> > plenty I don't understand - so long as you're b
On Sat, Aug 1, 2015 at 9:06 PM, Hugh Dickins wrote:
>
> (I don't actually understand why the clearing of DCACHE_ENTRY_TYPE in
> dentry_iput() is not of continuing concern; but don't worry, there's
> plenty I don't understand - so long as you're both satisfied that
> it's not a concern, no need to
On Sat, Aug 01, 2015 at 09:06:55PM -0700, Hugh Dickins wrote:
> (I don't actually understand why the clearing of DCACHE_ENTRY_TYPE in
> dentry_iput() is not of continuing concern; but don't worry, there's
> plenty I don't understand - so long as you're both satisfied that
> it's not a concern, no
On Sat, 1 Aug 2015, Linus Torvalds wrote:
>
> Well, I'd not be against continuing cleanups for 4.3... Well, as long
> as we can make sure 4.2 is solid first, of course. I'd still like to
> have Hugh verify that the current -git tree works for his load, but
> obviously that wasn't easily reproducib
On Sat, Aug 1, 2015 at 6:41 PM, Al Viro wrote:
>
> It feels like it might make sense to handle that in caller, but...
> that goes only for cases when we are *NOT* going to continue after
> successful transition to non-lazy mode. And these two are not of
> that sort - we do want to continue rather
On Sat, Aug 01, 2015 at 05:57:44PM -0700, Linus Torvalds wrote:
> Because it's not just that "!d_can_lookup()" case that triggers it,
> you also have that pattern in the RCU error case for may_lookup(), and
> get_link().
It feels like it might make sense to handle that in caller, but...
that goes
On Sat, Aug 1, 2015 at 5:23 PM, Al Viro wrote:
>
> Branch head should be at 97242f9, just to make sure you get
> the right one...
Ok, merged in my tree.
However, looking at this, I'm struck by how all the callers of
"link_path_walk()" tend to have very similar patterns wrt error
handling.
And I
On Sat, Aug 1, 2015 at 5:23 PM, Al Viro wrote:
>
> BTW, is there any convenient way to have git itself check things like
> that?
I guess you could just do a "pre-push" hook, and have it exit with an
error if the tree isn't clean (to fail the push) or at least warn.
See "man githooks" for details
On Sun, Aug 02, 2015 at 01:14:02AM +0100, Al Viro wrote:
> On Sat, Aug 01, 2015 at 09:09:24AM -0700, Linus Torvalds wrote:
>
> > Al, do you plan a pull request? It would be good to get this into rc5
> > (tomorrow) regardless of whether there might be other issues lurking
> > too.
>
> Please, pull
On Sat, Aug 01, 2015 at 09:09:24AM -0700, Linus Torvalds wrote:
> Al, do you plan a pull request? It would be good to get this into rc5
> (tomorrow) regardless of whether there might be other issues lurking
> too.
Please, pull from the usual place:
git://git.kernel.org/pub/scm/linux/kernel/git/vi
10 matches
Mail list logo