Re: [PATCH v2] btrfs: change BTRFS_MOUNT_* flags to 64bits

[David Sterba <dsterba@suse.cz>]

On Tue, Jul 16, 2024 at 08:11:00AM +0930, Qu Wenruo wrote:
> 
> 
> 在 2024/7/16 07:41, Qu Wenruo 写道:
> >
> >
> > 在 2024/7/15 22:01, David Sterba 写道:
> >> On Sat, Jul 13, 2024 at 07:45:08PM +0930, Qu Wenruo wrote:
> >>> Currently the BTRFS_MOUNT_* flags is already reaching 32 bits, and with
> >>> the incoming new rescue options, we're going beyond the width of 32
> >>> bits.
> >>>
> >>> This is going to cause problems as for quite some 32 bit systems,
> >>> 1ULL << 32 would overflow the width of unsigned long.
> >>>
> >>> Fix the problem by:
> >>>
> >>> - Migrate all existing BTRFS_MOUNT_* flags to unsigned long long
> >>> - Migrate all mount option related variables to unsigned long long
> >>>    * btrfs_fs_info::mount_opt
> >>>    * btrfs_fs_context::mount_opt
> >>>    * mount_opt parameter of btrfs_check_options()
> >>>    * old_opts parameter of btrfs_remount_begin()
> >>>    * old_opts parameter of btrfs_remount_cleanup()
> >>>    * mount_opt parameter of btrfs_check_mountopts_zoned()
> >>>    * mount_opt and opt parameters of check_ro_option()
> >>>
> >>> Signed-off-by: Qu Wenruo <wqu@suse.com>
> >>> ---
> >>> The current patch is still based on the latest for-next branch.
> >>>
> >>> But during merge time I will move this before the new rescue options.
> >>
> >> You konw you can't do that right? The branch for 6.11 can't be changed
> >> anymore and it was late last week already. I've forked the changes at
> >> 8e7860543a94784d744c7ce34b7 so far it's still subset of for-next if you
> >> change anything below that then it'll cause merge conflicts or would
> >> need manual resolution in another way. Until rc1 it's probably safest to
> >> just append to our for-next.
> >>
> >
> > I guess it's impossible to drop all the new rescue mount option patches
> > from 6.11 queue?
> 
> My bad, just see the git pull, so it's not possible anymore.
> 
> Then I just hope the patch can be merged as a bug fixes sooner, or we're
> going to be flooded by tons of compiling failures.

Yes a fixup is possible of course.