Re: linux-next: build failure after merge of the btrfs tree

[David Sterba <dsterba@suse.cz>]

On Thu, Oct 24, 2024 at 11:22:57AM +1030, Qu Wenruo wrote:
> 
> 
> 在 2024/10/24 11:17, David Sterba 写道:
> > On Thu, Oct 24, 2024 at 08:58:58AM +1030, Qu Wenruo wrote:
> >>
> >>
> >> 在 2024/10/24 08:27, Stephen Rothwell 写道:
> >>> Hi all,
> >>>
> >>> After merging the btrfs tree, today's linux-next build (x86_64
> >>> allmodconfig) failed like this:
> >>>
> >>> fs/btrfs/super.c: In function 'btrfs_reconfigure_for_mount':
> >>> fs/btrfs/super.c:2011:56: error: suggest parentheses around '&&' within '||' [-Werror=parentheses]
> >>>    2011 |         if (!fc->oldapi || !(fc->sb_flags & SB_RDONLY) && (mnt->mnt_sb->s_flags & SB_RDONLY))
> >>>         |                            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >>> cc1: all warnings being treated as errors
> >>>
> >>> Caused by commit
> >>>
> >>>     4642e430c55b ("btrfs: fix mount failure due to remount races")
> >>
> >> My bad, in fact a new patch is going to remove the oldapi check
> >> completely as newer mount using new API will break the per-subvolume
> >> RO/RW again.
> >>
> >> Thus a new patch is needed to remove the oldapi check first
> >> (https://lore.kernel.org/linux-btrfs/e1a70aa6dd0fc9ba6c7050a5befb3bd5b75a1377.1729664802.git.wqu@suse.com/),
> >> then the newer v2 patch
> >> (https://lore.kernel.org/linux-btrfs/08e45ca0-5ed9-4684-940f-1e956a936628@gmx.com/T/#t)
> >> will be completely fine.
> > 
> > I probably missed the v2 and picked the patch with warning that I did
> > not consider too serious but it seems linux-next builds with -Werrror.
> > Meanwhile I've updated the for-next snapshot branch and dropped the
> > patch.
> 
> I'd prefer to pick the v2 and its dependency ("btrfs: fix per-subvolume 
> RO/RW flags with new mount API") for early testing.
> 
> As I'm pretty sure the rolling distros are already rolling out new mount 
> using the fsconfig API, and breaking our per-subvolume RO/RW mount.
> 
> The promise that new mount API will solve the per-subvolume RO/RW 
> without reconfiguration is mostly a lie.
> The reality is, RO mount is still passed with both 
> fsconfig(FSCONFIG_SET_FLAG, "ro") and  mount_setattr(MOUNT_ATTR_RDONLY), 
> doing exactly the same thing as the old mount.

I'm monitoring the recent mount option problems, it's maybe due to
syzbot and/or various users noticing what does not work anymore after
the conversion to the new mount API in 6.8. Once the fixes are tested
they're on the fast track to be in the next RC. In particular the RO/RW
for subvolumes is maybe the most contentious change, but we have the use
case and it ultimately must work. I would not call it a 'lie', I don't
think there's an evil interest to break it, but we may be missing
testing coverage so we notice it a few releases later. Anyway, fixes for
mount option behaviour are always amenable for RC fixes.