From: Eric Sandeen <sandeen@redhat.com>
To: tytso@mit.edu
Cc: ext4 development <linux-ext4@vger.kernel.org>
Subject: [PATCH V2] ext4: handle optional-arg mount options better
Date: Mon, 15 Feb 2010 15:20:16 -0600 [thread overview]
Message-ID: <4B79BA90.3060703@redhat.com> (raw)
In-Reply-To: <20100215160150.GJ5337@thunk.org>
tytso@mit.edu wrote:
> On Wed, Feb 03, 2010 at 03:13:30PM -0600, Eric Sandeen wrote:
>
>> We have 2 mount options, "barrier" and "auto_da_alloc"
>> which may or may not take a 1/0 argument. This is confusing
>> the parser, it seems, because if we pass it without an
>> arg, it still tries to match_int for the arg, which
>> is uninitialized, and match_number uses those uninit from/to
>> values to do a kmalloc, resulting in potentially noisy
>> failures.
>>
>> I think just defining _arg variants of the tokens and
>> handling them separately is the simplest fix.
>>
>> Reported-by: Michael S. Tsirkin <mst@redhat.com>
>> Signed-off-by: Eric Sandeen <sandeen@redhat.com>
>> ---
>>
>
> This fix works just as well, and doesn't require _arg and _no_arg
> versions of the token tags.
>
> As long as we initialize arg[0], things should work correctly. They
> work correctly even without !args[0].from check, but I added that just
> in case the implementation of the match_token library function changes
> in the future.
>
Hm, I prefer the explicit to the clever. ;) But I guess it looks
mostly right.
This new code:
case Opt_barrier:
if (!args[0].from || match_int(&args[0], &option)) {
set_opt(sbi->s_mount_opt, BARRIER);
break;
}
takes a bit of thought for me to sort out what's going on.
I guess the first test is "if no argument was found" and the 2nd
is "if argument was found but can't be scanned?"
Previously we were relying on match_int failing for no args,
but now we test for that, explicitly so I think a match_int failure
should return an error (well 0) like every other call in the function.
Maybe something like this? I think it's clearer and more correct.
ext4: handle optional-arg mount options better
We have 2 mount options, "barrier" and "auto_da_alloc"
which may or may not take an argument. This is confusing
the parser, it seems, because if we pass it in without an
arg, it still tries to match_int for the arg, which
is uninitialized, and match_number() uses those uninitialized
from/to values to do a kmalloc, resulting in potentially noisy
failures.
Per Ted's suggestion, initialize the args struct so that
we know whether match_token() found an argument for the
option, and skip match_int() if not.
Also, return error (0) from parse_options if we thought
we found an argument, but match_int() Fails.
Reported-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
---
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 735c20d..d107d29 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -1229,6 +1229,11 @@ static int parse_options(char *options, struct super_block *sb,
if (!*p)
continue;
+ /*
+ * Initialize args struct so we know whether arg was found;
+ * Some options take optional arguments.
+ */
+ args[0].to = args[0].from = 0;
token = match_token(p, tokens, args);
switch (token) {
case Opt_bsd_df:
@@ -1518,10 +1523,13 @@ set_qf_format:
clear_opt(sbi->s_mount_opt, BARRIER);
break;
case Opt_barrier:
- if (match_int(&args[0], &option)) {
+ if (!args[0].from) {
+ /* No argument was found */
set_opt(sbi->s_mount_opt, BARRIER);
break;
}
+ if (match_int(&args[0], &option))
+ return 0;
if (option)
set_opt(sbi->s_mount_opt, BARRIER);
else
@@ -1594,10 +1602,13 @@ set_qf_format:
set_opt(sbi->s_mount_opt,NO_AUTO_DA_ALLOC);
break;
case Opt_auto_da_alloc:
- if (match_int(&args[0], &option)) {
+ if (!args[0].from) {
+ /* No argument was found */
clear_opt(sbi->s_mount_opt, NO_AUTO_DA_ALLOC);
break;
}
+ if (match_int(&args[0], &option))
+ return 0;
if (option)
clear_opt(sbi->s_mount_opt, NO_AUTO_DA_ALLOC);
else
next prev parent reply other threads:[~2010-02-15 21:20 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-03 21:13 [PATCH] handle optional-arg mount options better Eric Sandeen
2010-02-15 16:01 ` tytso
2010-02-15 21:20 ` Eric Sandeen [this message]
2010-02-16 1:19 ` [PATCH V2] ext4: " tytso
2010-02-16 3:23 ` Eric Sandeen
2010-02-16 17:28 ` Eric Sandeen
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=4B79BA90.3060703@redhat.com \
--to=sandeen@redhat.com \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
/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).