From: David Sterba <dsterba@suse.cz>
To: Anand Jain <anand.jain@oracle.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] btrfs: manage subvolid mount option as %u
Date: Tue, 13 Feb 2018 17:10:43 +0100 [thread overview]
Message-ID: <20180213161042.GV3003@twin.jikos.cz> (raw)
In-Reply-To: <20180213095048.9550-2-anand.jain@oracle.com>
On Tue, Feb 13, 2018 at 05:50:43PM +0800, Anand Jain wrote:
> As -o subvolid mount option is an u64 manage it as %u for
> token verifications, instead of %s.
>
> Signed-off-by: Anand Jain <anand.jain@oracle.com>
> ---
> fs/btrfs/super.c | 23 ++++++++++-------------
> 1 file changed, 10 insertions(+), 13 deletions(-)
>
> diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
> index 8112619cac95..bf629c8a6a47 100644
> --- a/fs/btrfs/super.c
> +++ b/fs/btrfs/super.c
> @@ -336,7 +336,7 @@ enum {
> static const match_table_t tokens = {
> {Opt_degraded, "degraded"},
> {Opt_subvol, "subvol=%s"},
> - {Opt_subvolid, "subvolid=%s"},
> + {Opt_subvolid, "subvolid=%u"},
This gets implemented as simple_strtoul, deep in the perser it uses an
unsigned long long and then casts to usigned long. Long and long-long
are same only on subset of architectures, so we'd need to either extend
teh parser capabilities to really do u64 or we'd have to use the %s and
match_u64.
Though a subvolid larger than full 32bit number is unlikely, for sake of
correctness I think we should stick to the constraints of the subvolid
that allows u64.
> {Opt_device, "device=%s"},
> {Opt_nodatasum, "nodatasum"},
> {Opt_datasum, "datasum"},
> @@ -964,8 +964,8 @@ static int btrfs_parse_subvol_options(const char *options, fmode_t flags,
> {
> substring_t args[MAX_OPT_ARGS];
> char *opts, *orig, *p;
> - char *num = NULL;
> int error = 0;
> + u64 subvolid;
>
> if (!options)
> return 0;
> @@ -995,18 +995,15 @@ static int btrfs_parse_subvol_options(const char *options, fmode_t flags,
> }
> break;
> case Opt_subvolid:
> - num = match_strdup(&args[0]);
> - if (num) {
> - *subvol_objectid = memparse(num, NULL);
> - kfree(num);
> - /* we want the original fs_tree */
> - if (!*subvol_objectid)
> - *subvol_objectid =
> - BTRFS_FS_TREE_OBJECTID;
> - } else {
> - error = -EINVAL;
> + error = match_u64(&args[0], &subvolid);
So this is the right way (with the %s), as memparse accepts the size
suffixes (K/M/G/...), that we don't want for a subvolume id.
> + if (error)
> goto out;
> - }
> +
> + /* we want the original fs_tree */
> + if (subvolid == 0)
> + subvolid = BTRFS_FS_TREE_OBJECTID;
> +
> + *subvol_objectid = subvolid;
> break;
> case Opt_subvolrootid:
> pr_warn("BTRFS: 'subvolrootid' mount option is deprecated and has no effect\n");
> --
> 2.7.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2018-02-13 16:12 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-13 9:50 [PATCH] btrfs: manage thread_pool mount option as %u Anand Jain
2018-02-13 9:50 ` [PATCH] btrfs: manage subvolid " Anand Jain
2018-02-13 16:10 ` David Sterba [this message]
2018-02-14 17:11 ` [PATCH v2] btrfs: verify subvolid mount parameter Anand Jain
2018-02-23 22:08 ` David Sterba
2018-02-14 17:15 ` [PATCH] btrfs: manage subvolid mount option as %u Anand Jain
2018-02-13 9:50 ` [PATCH] btrfs: manage metadata_ratio " Anand Jain
2018-02-13 9:50 ` [PATCH] btrfs: manage check_int_print_mask " Anand Jain
2018-02-13 9:50 ` [PATCH] btrfs: manage commit " Anand Jain
2018-02-13 9:50 ` [PATCH] btrfs: add a comment to mark the deprecated mount option Anand Jain
2018-02-13 9:50 ` [PATCH] btrfs: fix bare unsigned declarations Anand Jain
2018-02-13 16:58 ` David Sterba
2018-02-14 17:13 ` [PATCH v2] " Anand Jain
2018-02-23 22:12 ` David Sterba
2018-02-26 8:46 ` [PATCH v3] " Anand Jain
2018-03-07 16:07 ` David Sterba
2018-02-13 14:26 ` [PATCH] btrfs: manage thread_pool mount option as %u Nikolay Borisov
2018-02-13 15:18 ` Anand Jain
2018-02-13 15:34 ` Nikolay Borisov
2018-02-13 15:58 ` 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=20180213161042.GV3003@twin.jikos.cz \
--to=dsterba@suse.cz \
--cc=anand.jain@oracle.com \
--cc=linux-btrfs@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).