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@suse.com
[ 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.