Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753085AbbF0F4j (ORCPT ); Sat, 27 Jun 2015 01:56:39 -0400 Received: from wtarreau.pck.nerim.net ([62.212.114.60]:60984 "EHLO 1wt.eu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752621AbbF0F4c (ORCPT ); Sat, 27 Jun 2015 01:56:32 -0400 Date: Sat, 27 Jun 2015 07:56:19 +0200 From: Willy Tarreau To: Greg Kroah-Hartman Cc: Jari Ruusu , linux-kernel@vger.kernel.org, stable@vger.kernel.org, Al Viro Subject: Re: [PATCH 3.10 14/46] d_walk() might skip too much Message-ID: <20150627055619.GC21512@1wt.eu> References: <20150613171118.GB13001@1wt.eu> <20150619195434.GA22717@kroah.com> <20150627005216.GC29233@kroah.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150627005216.GC29233@kroah.com> User-Agent: Mutt/1.4.2.3i Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5289 Lines: 121 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 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 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 --- 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/