From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Willy Tarreau <w@1wt.eu>
Cc: Jari Ruusu <jariruusu@users.sourceforge.net>,
linux-kernel@vger.kernel.org, stable@vger.kernel.org,
Al Viro <viro@zeniv.linux.org.uk>
Subject: Re: [PATCH 3.10 14/46] d_walk() might skip too much
Date: Mon, 29 Jun 2015 17:37:01 -0700 [thread overview]
Message-ID: <20150630003701.GH6430@kroah.com> (raw)
In-Reply-To: <20150627055619.GC21512@1wt.eu>
On Sat, Jun 27, 2015 at 07:56:19AM +0200, Willy Tarreau wrote:
> 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@linuxfoundation.org> 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")
Ok, that's a mess, thanks for clearing it up for me, I've now included
this in the 3.10-stable kernel.
greg k-h
next prev parent reply other threads:[~2015-06-30 0:37 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-06 15:01 [PATCH 3.10 14/46] d_walk() might skip too much Jari Ruusu
2015-06-13 16:01 ` Jari Ruusu
2015-06-13 17:11 ` Willy Tarreau
2015-06-19 19:54 ` Greg Kroah-Hartman
2015-06-20 7:41 ` Jari Ruusu
2015-06-27 0:52 ` Greg Kroah-Hartman
2015-06-27 5:56 ` Willy Tarreau
2015-06-30 0:37 ` Greg Kroah-Hartman [this message]
2015-06-28 8:56 ` Jari Ruusu
-- strict thread matches above, loose matches on Subject: below --
2015-06-03 11:42 [PATCH 3.10 00/46] 3.10.80-stable review Greg Kroah-Hartman
2015-06-03 11:42 ` [PATCH 3.10 14/46] d_walk() might skip too much Greg Kroah-Hartman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150630003701.GH6430@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=jariruusu@users.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
--cc=w@1wt.eu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).