Re: [PATCH] btrfs: reject unknown mount options early

[David Sterba <dsterba@suse.cz>]

On Thu, Sep 28, 2023 at 08:42:20AM +0930, Qu Wenruo wrote:
> On 2023/9/28 08:26, Anand Jain wrote:
> > On 27/09/2023 09:13, Qu Wenruo wrote:
> >> [BUG]
> >> The following script would allow invalid mount options to be specified
> >> (although such invalid options would just be ignored):
> >>
> >>   # mkfs.btrfs -f $dev
> >>   # mount $dev $mnt1        <<< Successful mount expected
> >>   # mount $dev $mnt2 -o junk    <<< Failed mount expected
> >>   # echo $?
> >>   0
> >>
> >> [CAUSE]
> >> For the 2nd mount, since the fs is already mounted, we won't go through
> >> open_ctree() thus no btrfs_parse_options(), but only through
> >> btrfs_parse_subvol_options().
> >>
> >> However we do not treat unrecognized options from valid but irrelevant
> >> options, thus those invalid options would just be ignored by
> >> btrfs_parse_subvol_options().
> >>
> >> [FIX]
> >> Add the handling for Opt_error to handle invalid options and error out,
> >> while still ignore other valid options inside
> >> btrfs_parse_subvol_options().
> >
> > As discussed, the purpose of my report was to determine whether we still
> > need to return success when the 'junk' option is passed in the second
> > mount. I don't recall precisely if this is intentional, perhaps to
> > allow future features to remain compatible with the KAPI when
> > backported to an older kernel version, or if it may not be relevant in
> > this kernel version.
> 
> This is not intentional, purely a bug.

Yeah it's a bug, we need to split the mount option parsting due to
device and subvoulme to preprocess some things but any invalid option at
the first phase is also invalid in the second one so there's no reason
to skip checking.