Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Anand Jain <anand.jain@oracle.com>
To: Qu Wenruo <wqu@suse.com>, linux-btrfs@vger.kernel.org
Cc: David Sterba <dsterba@suse.cz>
Subject: Re: [PATCH] btrfs: reject unknown mount options early
Date: Thu, 28 Sep 2023 06:56:18 +0800	[thread overview]
Message-ID: <8b92ecee-e018-6570-880c-878919260e31@oracle.com> (raw)
In-Reply-To: <5c33940976b7f970836d8c796f92330e5072ffdc.1695777187.git.wqu@suse.com>




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.

Thanks, Anand


> 
> Reported-by: Anand Jain <anand.jain@oracle.com>
> Signed-off-by: Qu Wenruo <wqu@suse.com>
> ---
>   fs/btrfs/super.c | 4 ++++
>   1 file changed, 4 insertions(+)
> 
> diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
> index 5c6054f0552b..574fcff0822f 100644
> --- a/fs/btrfs/super.c
> +++ b/fs/btrfs/super.c
> @@ -911,6 +911,10 @@ static int btrfs_parse_subvol_options(const char *options, char **subvol_name,
>   
>   			*subvol_objectid = subvolid;
>   			break;
> +		case Opt_err:
> +			btrfs_err(NULL, "unrecognized mount option '%s'", p);
> +			error = -EINVAL;
> +			goto out;
>   		default:
>   			break;
>   		}

  parent reply	other threads:[~2023-09-27 22:56 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-27  1:13 [PATCH] btrfs: reject unknown mount options early Qu Wenruo
2023-09-27 15:32 ` David Sterba
2023-09-27 22:56 ` Anand Jain [this message]
2023-09-27 23:12   ` Qu Wenruo
2023-09-29 14:13     ` David Sterba

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8b92ecee-e018-6570-880c-878919260e31@oracle.com \
    --to=anand.jain@oracle.com \
    --cc=dsterba@suse.cz \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=wqu@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox