From: Rusty Russell <rusty@rustcorp.com.au>
To: Krzysztof Mazur <krzysiek@podlesie.net>
Cc: Pawel Moll <pawel.moll@arm.com>,
"linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH] init: fix in-place parameter modification regression
Date: Mon, 21 Oct 2013 12:27:10 +1030 [thread overview]
Message-ID: <871u3fmlmx.fsf@rustcorp.com.au> (raw)
In-Reply-To: <20131018091921.GA7301@shrek.podlesie.net>
Krzysztof Mazur <krzysiek@podlesie.net> writes:
> On Fri, Oct 18, 2013 at 02:20:38PM +1030, Rusty Russell wrote:
>> Back when there was almost no parameter parsing support, everyone got
>> used to keeping pointers into the original. Making everyone kstrdup()
>> seems like gratuitous churn which is likely to make more bugs.
>>
>> Your fix means __setup() gets treated specially, in that only it can
>> mangle the command line. That makes sense. But it introduces another
>> regression: normal parsing functions can't keep pointers, since that's
>> now __initdata.
>>
>> There are two possible solutions:
>> (1) Audit all __setup to make sure they copy if they want to mangle.
>> There are about 750 of them, but many are trivial.
>> (2) alloc_bootmem() a third commandline for parsing.
>>
>> Now, many functions of form __setup("XXX=") should be turned into
>> module_param anyway.
>>
>> I suggest we do (2) for the moment, and start sweeping through cleaning
>> up __setup() in the longer term.
>>
>
> Yes, the buffer cannot be __initdata. I'm sending an updated patch.
>
>
> However, keeping pointers to buffer, that will be reinitialized
> in next initcall parameters parsing pass, might cause some race
> conditions.
Thanks, applied.
Cheers,
Rusty.
> Thanks,
> Krzysiek
>
> -- >8 --
> Subject: [PATCH v2] init: fix in-place parameter modification regression
>
> Before commit 026cee0086fe1df4cf74691cf273062cc769617d
> ("params: <level>_initcall-like kernel parameters") the __setup
> parameter parsing code could modify parameter in the
> static_command_line buffer and such modifications were kept. After
> that commit such modifications are destroyed during per-initcall level
> parameter parsing because the same static_command_line buffer is used
> and only parameters for appropriate initcall level are parsed.
>
> That change broke at least parsing "ubd" parameter in the ubd driver
> when the COW file is used.
>
> Now the separate buffer is used for per-initcall parameter parsing.
>
> Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net>
> ---
> init/main.c | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/init/main.c b/init/main.c
> index 63d3e8f..c093b5c 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -132,6 +132,8 @@ char __initdata boot_command_line[COMMAND_LINE_SIZE];
> char *saved_command_line;
> /* Command line for parameter parsing */
> static char *static_command_line;
> +/* Command line for per-initcall parameter parsing */
> +static char *initcall_command_line;
>
> static char *execute_command;
> static char *ramdisk_execute_command;
> @@ -348,6 +350,7 @@ static inline void smp_prepare_cpus(unsigned int maxcpus) { }
> static void __init setup_command_line(char *command_line)
> {
> saved_command_line = alloc_bootmem(strlen (boot_command_line)+1);
> + initcall_command_line = alloc_bootmem(strlen (boot_command_line)+1);
> static_command_line = alloc_bootmem(strlen (command_line)+1);
> strcpy (saved_command_line, boot_command_line);
> strcpy (static_command_line, command_line);
> @@ -745,9 +748,9 @@ static void __init do_initcall_level(int level)
> extern const struct kernel_param __start___param[], __stop___param[];
> initcall_t *fn;
>
> - strcpy(static_command_line, saved_command_line);
> + strcpy(initcall_command_line, saved_command_line);
> parse_args(initcall_level_names[level],
> - static_command_line, __start___param,
> + initcall_command_line, __start___param,
> __stop___param - __start___param,
> level, level,
> &repair_env_string);
> --
> 1.8.4.1.635.g55556a5
prev parent reply other threads:[~2013-10-21 3:50 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-12 18:05 [PATCH] init: fix in-place parameter modification regression Krzysztof Mazur
2013-10-14 7:36 ` Rusty Russell
2013-10-14 9:28 ` Krzysztof Mazur
2013-10-14 11:34 ` Pawel Moll
2013-10-14 12:50 ` Krzysztof Mazur
2013-10-14 13:37 ` Pawel Moll
2013-10-18 3:50 ` Rusty Russell
2013-10-18 9:19 ` Krzysztof Mazur
2013-10-21 1:57 ` Rusty Russell [this message]
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=871u3fmlmx.fsf@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=akpm@linux-foundation.org \
--cc=krzysiek@podlesie.net \
--cc=linux-kernel@vger.kernel.org \
--cc=pawel.moll@arm.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 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.