* [PATCH 0/1] btrfs: Simplify parsing max_inline mount option
@ 2019-08-15 2:04 Vladimir Panteleev
2019-08-15 2:04 ` [PATCH 1/1] " Vladimir Panteleev
0 siblings, 1 reply; 7+ messages in thread
From: Vladimir Panteleev @ 2019-08-15 2:04 UTC (permalink / raw)
To: linux-btrfs; +Cc: Vladimir Panteleev
A nit I noticed when writing the global_reserve_size patch.
I'm assuming that rejecting garbage in mount options (where it was
silently accepted before) does not break the first rule of kernel
development?
Vladimir Panteleev (1):
btrfs: Simplify parsing max_inline mount option
fs/btrfs/super.c | 24 +++++++++---------------
1 file changed, 9 insertions(+), 15 deletions(-)
--
2.22.0
^ permalink raw reply [flat|nested] 7+ messages in thread
* [PATCH 1/1] btrfs: Simplify parsing max_inline mount option
2019-08-15 2:04 [PATCH 0/1] btrfs: Simplify parsing max_inline mount option Vladimir Panteleev
@ 2019-08-15 2:04 ` Vladimir Panteleev
2019-08-15 4:54 ` Anand Jain
2019-08-21 14:35 ` David Sterba
0 siblings, 2 replies; 7+ messages in thread
From: Vladimir Panteleev @ 2019-08-15 2:04 UTC (permalink / raw)
To: linux-btrfs; +Cc: Vladimir Panteleev
- Avoid an allocation;
- Properly handle non-numerical argument and garbage after numerical
argument.
Signed-off-by: Vladimir Panteleev <git@thecybershadow.net>
---
fs/btrfs/super.c | 24 +++++++++---------------
1 file changed, 9 insertions(+), 15 deletions(-)
diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index f56617dfb3cf..6fe8ef6667f3 100644
--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -426,7 +426,7 @@ int btrfs_parse_options(struct btrfs_fs_info *info, char *options,
unsigned long new_flags)
{
substring_t args[MAX_OPT_ARGS];
- char *p, *num;
+ char *p, *retptr;
u64 cache_gen;
int intarg;
int ret = 0;
@@ -630,22 +630,16 @@ int btrfs_parse_options(struct btrfs_fs_info *info, char *options,
info->thread_pool_size = intarg;
break;
case Opt_max_inline:
- num = match_strdup(&args[0]);
- if (num) {
- info->max_inline = memparse(num, NULL);
- kfree(num);
-
- if (info->max_inline) {
- info->max_inline = min_t(u64,
- info->max_inline,
- info->sectorsize);
- }
- btrfs_info(info, "max_inline at %llu",
- info->max_inline);
- } else {
- ret = -ENOMEM;
+ info->max_inline = memparse(args[0].from, &retptr);
+ if (retptr != args[0].to || info->max_inline == 0) {
+ ret = -EINVAL;
goto out;
}
+ info->max_inline = min_t(u64,
+ info->max_inline,
+ info->sectorsize);
+ btrfs_info(info, "max_inline at %llu",
+ info->max_inline);
break;
case Opt_alloc_start:
btrfs_info(info,
--
2.22.0
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH 1/1] btrfs: Simplify parsing max_inline mount option
2019-08-15 2:04 ` [PATCH 1/1] " Vladimir Panteleev
@ 2019-08-15 4:54 ` Anand Jain
2019-08-15 14:54 ` Vladimir Panteleev
2019-08-21 14:35 ` David Sterba
1 sibling, 1 reply; 7+ messages in thread
From: Anand Jain @ 2019-08-15 4:54 UTC (permalink / raw)
To: Vladimir Panteleev; +Cc: linux-btrfs
On 15/8/19 10:04 AM, Vladimir Panteleev wrote:
> - Avoid an allocation;
> - Properly handle non-numerical argument and garbage after numerical
> argument.
>
> Signed-off-by: Vladimir Panteleev <git@thecybershadow.net>
> ---
> fs/btrfs/super.c | 24 +++++++++---------------
> 1 file changed, 9 insertions(+), 15 deletions(-)
>
> diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
> index f56617dfb3cf..6fe8ef6667f3 100644
> --- a/fs/btrfs/super.c
> +++ b/fs/btrfs/super.c
> @@ -426,7 +426,7 @@ int btrfs_parse_options(struct btrfs_fs_info *info, char *options,
> unsigned long new_flags)
> {
> substring_t args[MAX_OPT_ARGS];
> - char *p, *num;
> + char *p, *retptr;
> u64 cache_gen;
> int intarg;
> int ret = 0;
> @@ -630,22 +630,16 @@ int btrfs_parse_options(struct btrfs_fs_info *info, char *options,
> info->thread_pool_size = intarg;
> break;
> case Opt_max_inline:
> - num = match_strdup(&args[0]);
> - if (num) {
> - info->max_inline = memparse(num, NULL);
> - kfree(num);
> -
> - if (info->max_inline) {
> - info->max_inline = min_t(u64,
> - info->max_inline,
> - info->sectorsize);
> - }
> - btrfs_info(info, "max_inline at %llu",
> - info->max_inline);
> - } else {
> - ret = -ENOMEM;
> + info->max_inline = memparse(args[0].from, &retptr);
> + if (retptr != args[0].to || info->max_inline == 0) {
> + ret = -EINVAL;
> goto out;
This causes regression, max_inline = 0 is a valid parameter.
Thanks, Anand
> }
> + info->max_inline = min_t(u64,
> + info->max_inline,
> + info->sectorsize);
> + btrfs_info(info, "max_inline at %llu",
> + info->max_inline);
> break;
> case Opt_alloc_start:
> btrfs_info(info,
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 1/1] btrfs: Simplify parsing max_inline mount option
2019-08-15 4:54 ` Anand Jain
@ 2019-08-15 14:54 ` Vladimir Panteleev
0 siblings, 0 replies; 7+ messages in thread
From: Vladimir Panteleev @ 2019-08-15 14:54 UTC (permalink / raw)
To: Anand Jain; +Cc: Btrfs BTRFS
On Thu, 15 Aug 2019 at 04:54, Anand Jain <anand.jain@oracle.com> wrote:
> This causes regression, max_inline = 0 is a valid parameter.
Thank you for catching that. Apologies for making such a rudimentary mistake.
I will apply more diligence and resubmit.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 1/1] btrfs: Simplify parsing max_inline mount option
2019-08-15 2:04 ` [PATCH 1/1] " Vladimir Panteleev
2019-08-15 4:54 ` Anand Jain
@ 2019-08-21 14:35 ` David Sterba
2019-08-21 15:16 ` Vladimir Panteleev
1 sibling, 1 reply; 7+ messages in thread
From: David Sterba @ 2019-08-21 14:35 UTC (permalink / raw)
To: Vladimir Panteleev; +Cc: linux-btrfs
On Thu, Aug 15, 2019 at 02:04:53AM +0000, Vladimir Panteleev wrote:
> - Avoid an allocation;
> - Properly handle non-numerical argument and garbage after numerical
> argument.
>
> Signed-off-by: Vladimir Panteleev <git@thecybershadow.net>
> ---
> fs/btrfs/super.c | 24 +++++++++---------------
> 1 file changed, 9 insertions(+), 15 deletions(-)
>
> diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
> index f56617dfb3cf..6fe8ef6667f3 100644
> --- a/fs/btrfs/super.c
> +++ b/fs/btrfs/super.c
> @@ -426,7 +426,7 @@ int btrfs_parse_options(struct btrfs_fs_info *info, char *options,
> unsigned long new_flags)
> {
> substring_t args[MAX_OPT_ARGS];
> - char *p, *num;
> + char *p, *retptr;
> u64 cache_gen;
> int intarg;
> int ret = 0;
> @@ -630,22 +630,16 @@ int btrfs_parse_options(struct btrfs_fs_info *info, char *options,
> info->thread_pool_size = intarg;
> break;
> case Opt_max_inline:
> - num = match_strdup(&args[0]);
> - if (num) {
> - info->max_inline = memparse(num, NULL);
> - kfree(num);
> -
> - if (info->max_inline) {
> - info->max_inline = min_t(u64,
> - info->max_inline,
> - info->sectorsize);
> - }
> - btrfs_info(info, "max_inline at %llu",
> - info->max_inline);
> - } else {
> - ret = -ENOMEM;
> + info->max_inline = memparse(args[0].from, &retptr);
I don't think this is a good idea, match_strdup takes an opaque type
substring_t that is used by the parser. So accessing ::from directly in
memparse does not respect the API boundary. I've checked some other
usages in the tree and the match_strdup/memparse/kstrtoull is quite
common.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 1/1] btrfs: Simplify parsing max_inline mount option
2019-08-21 14:35 ` David Sterba
@ 2019-08-21 15:16 ` Vladimir Panteleev
2019-08-21 16:08 ` David Sterba
0 siblings, 1 reply; 7+ messages in thread
From: Vladimir Panteleev @ 2019-08-21 15:16 UTC (permalink / raw)
To: dsterba, Btrfs BTRFS
On Wed, 21 Aug 2019 at 14:35, David Sterba <dsterba@suse.cz> wrote:
> match_strdup takes an opaque type
> substring_t that is used by the parser.
Sorry, how would one determine that the type is opaque?
> I've checked some other
> usages in the tree and the match_strdup/memparse/kstrtoull is quite
> common.
Sorry, I also see there are places where substring_t's .from / .to are
still accessed directly (including in btrfs code). Do you think they
ought to use match_strdup instead?
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 1/1] btrfs: Simplify parsing max_inline mount option
2019-08-21 15:16 ` Vladimir Panteleev
@ 2019-08-21 16:08 ` David Sterba
0 siblings, 0 replies; 7+ messages in thread
From: David Sterba @ 2019-08-21 16:08 UTC (permalink / raw)
To: Vladimir Panteleev; +Cc: dsterba, Btrfs BTRFS
On Wed, Aug 21, 2019 at 03:16:11PM +0000, Vladimir Panteleev wrote:
> On Wed, 21 Aug 2019 at 14:35, David Sterba <dsterba@suse.cz> wrote:
> > match_strdup takes an opaque type
> > substring_t that is used by the parser.
>
> Sorry, how would one determine that the type is opaque?
It's a typedef, which is kind of indication "don't look inside" as the
kernel coding does not normally use typedefs.
> > I've checked some other
> > usages in the tree and the match_strdup/memparse/kstrtoull is quite
> > common.
>
> Sorry, I also see there are places where substring_t's .from / .to are
> still accessed directly (including in btrfs code). Do you think they
> ought to use match_strdup instead?
You're right, the compression option parsing references ::from heavily.
So for temporary use it would be ok to avoid the allocation, which means
match_strdup would be used only in btrfs_parse_subvol_options.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2019-08-21 16:07 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-08-15 2:04 [PATCH 0/1] btrfs: Simplify parsing max_inline mount option Vladimir Panteleev
2019-08-15 2:04 ` [PATCH 1/1] " Vladimir Panteleev
2019-08-15 4:54 ` Anand Jain
2019-08-15 14:54 ` Vladimir Panteleev
2019-08-21 14:35 ` David Sterba
2019-08-21 15:16 ` Vladimir Panteleev
2019-08-21 16:08 ` David Sterba
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.