From: Qu Wenruo <wqu@suse.com>
To: David Disseldorp <ddiss@suse.de>, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] btrfs: drop unused memparse() parameter
Date: Thu, 7 Dec 2023 13:01:50 +1030 [thread overview]
Message-ID: <19fc847b-7df6-41fc-ad52-f4e7f6d13201@suse.com> (raw)
In-Reply-To: <20231205111329.6652-1-ddiss@suse.de>
[-- Attachment #1.1.1: Type: text/plain, Size: 1581 bytes --]
On 2023/12/5 21:43, David Disseldorp wrote:
> The @retptr parameter for memparse() is optional.
> btrfs_devinfo_scrub_speed_max_store() doesn't use it for any input
> validation, so the parameter can be dropped.
To me, I believe it's better to completely get rid of memparse().
As you already found out, some suffix, especially "e|E" can screw up the
result.
E.g. "25e" would be interpreted as 25 with "e" as suffix, which is fine
according to the rule. (without prefix, the base is 10, so only "25" is
valid. Then the remaining part is interpreted as suffix).
And since btrfs is not going to do pretty size output for sysfs (as most
sysfs is not directly for end users, and we need accurate output), to be
consistent there isn't much need for suffix handling either.
So can't we just replace memparse() with kstrtoull()?
Thanks,
Qu
>
> Signed-off-by: David Disseldorp <ddiss@suse.de>
> ---
> fs/btrfs/sysfs.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/fs/btrfs/sysfs.c b/fs/btrfs/sysfs.c
> index e6b51fb3ddc1e..75f3b774a4d83 100644
> --- a/fs/btrfs/sysfs.c
> +++ b/fs/btrfs/sysfs.c
> @@ -1779,10 +1779,9 @@ static ssize_t btrfs_devinfo_scrub_speed_max_store(struct kobject *kobj,
> {
> struct btrfs_device *device = container_of(kobj, struct btrfs_device,
> devid_kobj);
> - char *endptr;
> unsigned long long limit;
>
> - limit = memparse(buf, &endptr);
> + limit = memparse(buf, NULL);
> WRITE_ONCE(device->scrub_speed_max, limit);
> return len;
> }
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7027 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]
next prev parent reply other threads:[~2023-12-07 2:31 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-05 11:13 [PATCH] btrfs: drop unused memparse() parameter David Disseldorp
2023-12-05 12:48 ` Johannes Thumshirn
2023-12-05 14:22 ` David Sterba
2023-12-06 0:21 ` David Disseldorp
2023-12-06 18:53 ` David Sterba
2023-12-06 23:52 ` David Disseldorp
2023-12-07 13:55 ` David Sterba
2023-12-08 0:41 ` [PATCH] btrfs: validate scrub_speed_max sysfs string David Disseldorp
2023-12-11 3:18 ` Qu Wenruo
2023-12-11 3:56 ` David Disseldorp
2023-12-13 22:50 ` David Sterba
2023-12-13 22:52 ` David Sterba
2023-12-07 2:31 ` Qu Wenruo [this message]
2023-12-07 12:15 ` [PATCH] btrfs: drop unused memparse() parameter David Sterba
2023-12-07 19:56 ` Qu Wenruo
2023-12-13 23:15 ` David Sterba
2023-12-13 23:46 ` Qu Wenruo
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=19fc847b-7df6-41fc-ad52-f4e7f6d13201@suse.com \
--to=wqu@suse.com \
--cc=ddiss@suse.de \
--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