On Wed, Aug 07, 2019 at 12:51:26PM +0200, Greg KH wrote:
> On Wed, Aug 07, 2019 at 11:47:59AM +0200, David Sterba wrote:
> > On Tue, Aug 06, 2019 at 05:35:00PM -0400, Sasha Levin wrote:
> > > From: Filipe Manana <fdmanana@xxxxxxxx>
> > >
> > > [ Upstream commit a6d155d2e363f26290ffd50591169cb96c2a609e ]
> > >
> > > Fixes: 03628cdbc64db6 ("Btrfs: do not start a transaction during fiemap")
> >
> > The commit is a regression fix during the 5.2 cycle, how it could end up
> > in a 4.19 stable candidate?
> >
> > $ git describe 03628cdbc64db6
> > v5.1-rc7-201-g03628cdbc64d
> >
> > $ git describe --contains 03628cdbc64db6
> > v5.2-rc1~163^2~26
> >
> > And it does not belong to 5.2 either, git cherry-pick on top of 5.2
> > fails.
> >
> > I think such sanity check can be done automatically so the patches don't
> > accidentally land in trees where don't belong.
>
>
> Commit 03628cdbc64d ("Btrfs: do not start a transaction during fiemap")
> was tagged for the stable trees, and ended up in the following releases:
> 4.14.121 4.19.45 5.0.18 5.1.4 5.2
> so yes, it does need to go back to all of those locations if this patch
> really does fix the issue there.
You're right, I did not notice the CC tag when examining the patches.
