[PATCH] MIPS: Make local arrays with CL_SIZE static __initdata

[Atsushi Nemoto]

Since commit 22242681 ("MIPS: Extend COMMAND_LINE_SIZE"), CL_SIZE is
4096 and local array variables with this size will cause an build
failure with default CONFIG_FRAME_WARN settings.

Although current users of such array variables are all early bootstrap
code and might not cause real stack overflow (thread_info corruption),
it would be safe to declare these arrays static with __initdata.

Signed-off-by: Atsushi Nemoto <anemo@...>
---
 arch/mips/bcm47xx/prom.c           |    2 +-
 arch/mips/mti-malta/malta-memory.c |    3 ++-
 arch/mips/rb532/prom.c             |    2 +-
 arch/mips/txx9/generic/setup.c     |    4 ++--
 4 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/arch/mips/bcm47xx/prom.c b/arch/mips/bcm47xx/prom.c
index 079e33d..fb284c3 100644
--- a/arch/mips/bcm47xx/prom.c
+++ b/arch/mips/bcm47xx/prom.c
@@ -100,7 +100,7 @@ static __init void prom_init_console(void)
 
 static __init void prom_init_cmdline(void)
 {
- char buf[CL_SIZE];
+ static char buf[CL_SIZE] __initdata;
 
  /* Get the kernel command line from CFE */
  if (cfe_getenv("LINUX_CMDLINE", buf, CL_SIZE) >= 0) {
diff --git a/arch/mips/mti-malta/malta-memory.c b/arch/mips/mti-malta/malta-memory.c
index 61888ff..9035c64 100644
--- a/arch/mips/mti-malta/malta-memory.c
+++ b/arch/mips/mti-malta/malta-memory.c
@@ -54,7 +54,8 @@ static struct prom_pmemblock * __init prom_getmdesc(void)
 {
  char *memsize_str;
  unsigned int memsize;
- char cmdline[CL_SIZE], *ptr;
+ char *ptr;
+ static char cmdline[CL_SIZE] __initdata;
 
  /* otherwise look in the environment */
  memsize_str = prom_getenv("memsize");
diff --git a/arch/mips/rb532/prom.c b/arch/mips/rb532/prom.c
index 46ca24d..ad5bd10 100644
--- a/arch/mips/rb532/prom.c
+++ b/arch/mips/rb532/prom.c
@@ -69,7 +69,7 @@ static inline unsigned long tag2ul(char *arg, const char *tag)
 
 void __init prom_setup_cmdline(void)
 {
- char cmd_line[CL_SIZE];
+ static char cmd_line[CL_SIZE] __initdata;
  char *cp, *board;
  int prom_argc;
  char **prom_argv, **prom_envp;
diff --git a/arch/mips/txx9/generic/setup.c b/arch/mips/txx9/generic/setup.c
index e10184c..d66802e 100644
--- a/arch/mips/txx9/generic/setup.c
+++ b/arch/mips/txx9/generic/setup.c
@@ -160,7 +160,7 @@ static void __init prom_init_cmdline(void)
  int argc;
  int *argv32;
  int i; /* Always ignore the "-c" at argv[0] */
- char builtin[CL_SIZE];
+ static char builtin[CL_SIZE] __initdata;
 
  if (fw_arg0 >= CKSEG0 || fw_arg1 < CKSEG0) {
  /*
@@ -315,7 +315,7 @@ static inline void txx9_cache_fixup(void)
 
 static void __init preprocess_cmdline(void)
 {
- char cmdline[CL_SIZE];
+ static char cmdline[CL_SIZE] __initdata;
  char *s;
 
  strcpy(cmdline, arcs_cmdline);
--
1.5.6.5

[Dmitri Vorobiev]

On Sat, Nov 7, 2009 at 7:20 PM, Atsushi Nemoto <anemo@...> wrote:

> Since commit 22242681 ("MIPS: Extend COMMAND_LINE_SIZE"), CL_SIZE is
> 4096 and local array variables with this size will cause an build
> failure with default CONFIG_FRAME_WARN settings.
>
> Although current users of such array variables are all early bootstrap
> code and might not cause real stack overflow (thread_info corruption),
> it would be safe to declare these arrays static with __initdata.
>
> Signed-off-by: Atsushi Nemoto <anemo@...>
> ---
>  arch/mips/bcm47xx/prom.c           |    2 +-
>  arch/mips/mti-malta/malta-memory.c |    3 ++-
>  arch/mips/rb532/prom.c             |    2 +-
>  arch/mips/txx9/generic/setup.c     |    4 ++--
>  4 files changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/arch/mips/bcm47xx/prom.c b/arch/mips/bcm47xx/prom.c
> index 079e33d..fb284c3 100644
> --- a/arch/mips/bcm47xx/prom.c
> +++ b/arch/mips/bcm47xx/prom.c
> @@ -100,7 +100,7 @@ static __init void prom_init_console(void)
>
>  static __init void prom_init_cmdline(void)
>  {
> -       char buf[CL_SIZE];
> +       static char buf[CL_SIZE] __initdata;

If this is intended for -queue, this patch won't apply, because
CL_SIZE was recently removed in favor of using CONFIG_CMDLINE_SIZE
directly.

Also, I think it's more common to place __initdata before the variable
name, not after it, although tastes do differ. :)

Thanks,
Dmitri

[Maciej W. Rozycki]

On Sat, 7 Nov 2009, Dmitri Vorobiev wrote:

> Also, I think it's more common to place __initdata before the variable
> name, not after it, although tastes do differ. :)

 Well, <linux/init.h> disagrees.

  Maciej

[Dmitri Vorobiev]

On Sat, Nov 7, 2009 at 9:14 PM, Maciej W. Rozycki <macro@...> wrote:
> On Sat, 7 Nov 2009, Dmitri Vorobiev wrote:
>
>> Also, I think it's more common to place __initdata before the variable
>> name, not after it, although tastes do differ. :)
>
>  Well, <linux/init.h> disagrees.

Indeed. Thanks for the correction.

Dmitri

>
>  Maciej
>

[Atsushi Nemoto]

On Sat, 7 Nov 2009 20:16:57 +0200, Dmitri Vorobiev <dmitri.vorobiev@...> wrote:

> > --- a/arch/mips/bcm47xx/prom.c
> > +++ b/arch/mips/bcm47xx/prom.c
> > @@ -100,7 +100,7 @@ static __init void prom_init_console(void)
> >
> >  static __init void prom_init_cmdline(void)
> >  {
> > -       char buf[CL_SIZE];
> > +       static char buf[CL_SIZE] __initdata;
>
> If this is intended for -queue, this patch won't apply, because
> CL_SIZE was recently removed in favor of using CONFIG_CMDLINE_SIZE
> directly.

Oh I missed your CL_SIZE removal patch.  Anyway I want this patch for
2.6.32 since this is regression.

If the CL_SIZE removal patch was merged for 2.6.32 first, I will
update my patch.  Othersize, your patch needs update, but I suppose we
can do it easily.  Of course Ralf can do it too ;)

---
Atsushi Nemoto

[Ralf Baechle DL5RB]

On Sun, Nov 08, 2009 at 02:20:37AM +0900, Atsushi Nemoto wrote:

> Since commit 22242681 ("MIPS: Extend COMMAND_LINE_SIZE"), CL_SIZE is
> 4096 and local array variables with this size will cause an build
> failure with default CONFIG_FRAME_WARN settings.
>
> Although current users of such array variables are all early bootstrap
> code and might not cause real stack overflow (thread_info corruption),
> it would be safe to declare these arrays static with __initdata.
>
> Signed-off-by: Atsushi Nemoto <anemo@...>

Applied, thanks!

  Ralf