Re: [PATCH 3.10 14/46] d_walk() might skip too much

[Willy Tarreau]

On Fri, Jun 26, 2015 at 05:52:16PM -0700, Greg Kroah-Hartman wrote:
> On Sat, Jun 20, 2015 at 10:41:14AM +0300, Jari Ruusu wrote:
> > On 6/19/15, Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> > > I would much rather just include the "real" upstream patches, instead of
> > > an odd backport.
> > >
> > > Jari, can you just backport the above referenced patches instead and
> > > provide those backports?
> > 
> > I won't do that, sorry. It is more complicated than you think. It would
> > involve backporting more VFS-re-write-patch-bombs than would be acceptable
> > to stable kernel branch. Above mentioned d_walk() function that Al Viro
> > modified in mainline don't even exist in 3.10.y and older brances.
> > 
> > My understanding is that complete backport of above mentioned "deal with
> > deadlock in d_walk()" and "d_walk() might skip too much" patches to 3.10.y
> > branch is to apply all these patches:
> > 
> > (a) backport of "deal with deadlock in d_walk()", by Ben Hutchings
> > (b) dcache: Fix locking bugs in backported "deal with deadlock in d_walk()"
> > (c) Al Viro's "d_walk() might skip too much" applied THREE times.
> > 
> > Of those, you merged (a) and (b) to 3.10.76 stable, and one copy of (c) to
> > 3.10.80 stable.
> > 
> > The problem is that you didn't realize that "deal with deadlock in d_walk()"
> > was applied to three different places in Ben Hutchings' backport, and that
> > latest Al Viro's fix had to be also applied to three different places.
> > Considering the sh*t that you have to deal with, nobody is blaming you for
> > that mistake.
> > 
> > I am asking that you apply Al Viro's original "d_walk() might skip too much"
> > patch TWO more times to 3.10.y stable branch. On both times, your patch tool
> > will find the correct place of source file to modify, but with different
> > offsets each time.
> 
> That's insane, and not how my tools work :(

No but I think it's just the patch command who found the proper location
because the context was identical. That's what happens to me all the time
with very old kernels, which is the reason why I must absolutely build
them before the preview otherwise I'm sure to deliver something that
doesn't even build :-)

> Can you provide the needed backport?  If it was in an earlier email in
> this series, sorry, it's long gone from my mailbox, can you resend it?

Yes it was in the thread earlier this month. I'm appending it below. The
following commits were referred to :
  - ca5358e ("deal with deadlock in d_walk()")                                  
  - 2159184 ("d_walk() might skip too much")                                    

Regards,
Willy

Date:	Sat, 13 Jun 2015 19:01:31 +0300
Subject: Re: [PATCH 3.10 14/46] d_walk() might skip too much
From: Jari Ruusu <jariruusu@xxxxxxxxxxxxxxxxxxxxx>

When Al Viro's VFS deadlock fix "deal with deadlock in d_walk()" was
backported to 3.10.y 3.4.y and 3.2.y stable kernel brances, the deadlock fix
was copied to 3 different places. Later, a bug in that code was discovered.
Al Viro's fix involved fixing only one part of code in mainline kernel. That
fix is called "d_walk() might skip too much".

3.10.y 3.4.y and 3.2.y stable kernel brances need that later fix copied to 3
different places. Greg Kroah-Hartman included Al Viro's "d_walk() might skip
too much" fix only once in 3.10.80 kernel, leaving 2 more places without a
fix.

The patch below was not written by me. I only applied Al Viro's "d_walk()
might skip too much" fix 2 more times to 3.10.80 kernel, and cheched that
the fixes went to correct places. With this patch applied, all 3 places that
I am aware of 3.10.y stable branch are now fixed.

Signed-off-by: Jari Ruusu <jariruusu@xxxxxxxxxxxxxxxxxxxxx>

--- linux-3.10.80/fs/dcache.c.OLD	2015-06-11 19:22:31.000000000 +0300
+++ linux-3.10.80/fs/dcache.c	2015-06-11 19:32:59.000000000 +0300
@@ -1053,13 +1053,13 @@
 		/* might go back up the wrong parent if we have had a rename. */
 		if (!locked && read_seqretry(&rename_lock, seq))
 			goto rename_retry;
-		next = child->d_child.next;
-		while (unlikely(child->d_flags & DCACHE_DENTRY_KILLED)) {
+		/* go into the first sibling still alive */
+		do {
+			next = child->d_child.next;
 			if (next == &this_parent->d_subdirs)
 				goto ascend;
 			child = list_entry(next, struct dentry, d_child);
-			next = next->next;
-		}
+		} while (unlikely(child->d_flags & DCACHE_DENTRY_KILLED));
 		rcu_read_unlock();
 		goto resume;
 	}
@@ -2977,13 +2977,13 @@
 		/* might go back up the wrong parent if we have had a rename. */
 		if (!locked && read_seqretry(&rename_lock, seq))
 			goto rename_retry;
-		next = child->d_child.next;
-		while (unlikely(child->d_flags & DCACHE_DENTRY_KILLED)) {
+		/* go into the first sibling still alive */
+		do {
+			next = child->d_child.next;
 			if (next == &this_parent->d_subdirs)
 				goto ascend;
 			child = list_entry(next, struct dentry, d_child);
-			next = next->next;
-		}
+		} while (unlikely(child->d_flags & DCACHE_DENTRY_KILLED));
 		rcu_read_unlock();
 		goto resume;
 	}

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/