Re: [PATCH][RFC] Drop the "static __initdata" from tmp_cmdline in parse_early_param().

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 13 Sep 2007, Thomas Petazzoni wrote:

> Hi,
>
> Robert P. J. Day wrote:
>
> > --- a/init/main.c
> > +++ b/init/main.c
> > @@ -482,7 +482,7 @@ static int __init do_early_param(char *param, char *val)
> >  void __init parse_early_param(void)
> >  {
> >  	static __initdata int done = 0;
> > -	static __initdata char tmp_cmdline[COMMAND_LINE_SIZE];
> > +	char tmp_cmdline[COMMAND_LINE_SIZE];
>
> As I've said in an answer to an e-mail from you on the kernelnewbies
> mailing list, this change is going to allocate 2k on the stack,
> which is quite big compared to the overall stack size. If you use 8k
> stacks, it may still work, but with 4k stacks, it eats half of the
> stack, leaving only 2k for the rest of the code to execute, which
> may not be enough. I think that why this buffer is static.

  as a (sort of) related followup to the above, note that having
dropped the "static __initdata" would have had a nasty effect on any
__setup or early_param-registered setup functions that assumed that
the data at the address they were passed was going to persist, or
assumed that they could write back to that address.

  but technically, that's not disallowed.  look at the layout of the
relevant structure:

struct obs_kernel_param {
        const char *str;
        int (*setup_func)(char *);
        int early;
};

  note that the setup_func accepts "char *" as opposed to "const char
*".  any legitimate reason for that?  are there, in fact, any of those
setup functions anywhere in the tree that try to modify the data back
at that passed address?  i would have assumed not, but i haven't
looked closely enough.

rday
-- 
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://crashcourse.ca
========================================================================
-
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Kernel Development]     [Kernel Announce]     [Kernel Newbies]     [Linux Networking Development]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Device Mapper]

  Powered by Linux