Re: error in backport of 'btrfs: fix possible free space tree corruption with online conversion'

[David Sterba <dsterba@suse.cz>]

On Fri, Feb 19, 2021 at 05:12:12PM +0100, Holger Hoffstätte wrote:
> On 2021-02-19 16:20, Wang Yugui wrote:
> > --- a/fs/btrfs/ctree.h
> > +++ b/fs/btrfs/ctree.h
> > @@ -146,6 +146,9 @@ enum {
> >   	BTRFS_FS_STATE_DEV_REPLACING,
> >   	/* The btrfs_fs_info created for self-tests */
> >   	BTRFS_FS_STATE_DUMMY_FS_INFO,
> > +
> > +	/* Indicate that we can't trust the free space tree for caching yet */
> > +	BTRFS_FS_FREE_SPACE_TREE_UNTRUSTED,
> >   };
> >   
> >   #define BTRFS_BACKREF_REV_MAX		256
> > 
> > Both the line(Line:146 vs Line:564) and the content are wrong.
> > 
> 
> Ahh..now I understand, indeed the merge of BTRFS_FS_FREE_SPACE_TREE_UNTRUSTED went into
> the wrong enum. I misunderstood your original posting to mean that it had somehow missed
> a chunk or used the wrong enum value in set_bit.
> 
> Anyway, good catch! I guess Dave needs to decide how to fix this, maybe
> let Greg revert & re-apply properly.
> 
> Can anybody explain why git decided to do this?

Git finds that the patch does not apply and lets the user to fix it.

I did git cherry-pick of 2f96e40212d435b3284 on v5.10.12 and got 2
conflicts:

first was in caching_thread around

	if (btrfs_fs_compat_ro(fs_info, FREE_SPACE_TREE))

that got resolved correctly, and the second one in the enum, but the
conflict was suggested in the right enum (lines 559+), so all I had to
do was to remove unmatched context and the <<< >>> markers. It's
possible that git version could affect that, mine is 2.29.2. Or stable
team does not use git for the intermediate patches and quilt did not get
it right.

I doubt that the conflict resolution was done incorrectly by hand, the
enums are quite far away so it would not be just a trivial change (like
context fixups) that are in the scope of semi-automatic stable
backports.