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 :( 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? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html