* COMMAND_LINE_SIZE and CONFIG_FRAME_WARN @ 2009-11-06 16:08 Atsushi Nemoto 2009-11-06 16:10 ` Atsushi Nemoto ` (3 more replies) 0 siblings, 4 replies; 15+ messages in thread From: Atsushi Nemoto @ 2009-11-06 16:08 UTC (permalink / raw) To: linux-mips Recently COMMAND_LINE_SIZE (CL_SIZE) was extended to 4096 from 512. (commit 22242681 "MIPS: Extend COMMAND_LINE_SIZE") This cause warning if something like buf[CL_SIZE] was declared as a local variable, for example in prom_init_cmdline() on some platforms. And since many Makefiles in arch/mips enables -Werror, this cause build failure. How can we avoid this error? - do not use local array? (but dynamic allocation cannot be used in such an early stage. static array?) - are there any way to disable -Wframe-larger-than for the file or function? - make COMMAND_LINE_SIZE customizable? - use non default CONFIG_FRAME_WARN? Any comments or suggestions? --- Atsushi Nemoto ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: COMMAND_LINE_SIZE and CONFIG_FRAME_WARN 2009-11-06 16:08 COMMAND_LINE_SIZE and CONFIG_FRAME_WARN Atsushi Nemoto @ 2009-11-06 16:10 ` Atsushi Nemoto 2009-11-06 16:18 ` Wu Zhangjin ` (2 subsequent siblings) 3 siblings, 0 replies; 15+ messages in thread From: Atsushi Nemoto @ 2009-11-06 16:10 UTC (permalink / raw) To: linux-mips On Sat, 07 Nov 2009 01:08:39 +0900 (JST), Atsushi Nemoto <anemo@mba.ocn.ne.jp> wrote: > Recently COMMAND_LINE_SIZE (CL_SIZE) was extended to 4096 from 512. > (commit 22242681 "MIPS: Extend COMMAND_LINE_SIZE") Excuse me, old COMMAND_LINE_SIZE value was 256, not 512. --- Atsushi Nemoto ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: COMMAND_LINE_SIZE and CONFIG_FRAME_WARN 2009-11-06 16:08 COMMAND_LINE_SIZE and CONFIG_FRAME_WARN Atsushi Nemoto 2009-11-06 16:10 ` Atsushi Nemoto @ 2009-11-06 16:18 ` Wu Zhangjin 2009-11-06 16:22 ` Dmitri Vorobiev 2009-11-06 16:34 ` Maciej W. Rozycki 3 siblings, 0 replies; 15+ messages in thread From: Wu Zhangjin @ 2009-11-06 16:18 UTC (permalink / raw) To: Atsushi Nemoto; +Cc: linux-mips On Sat, 2009-11-07 at 01:08 +0900, Atsushi Nemoto wrote: > Recently COMMAND_LINE_SIZE (CL_SIZE) was extended to 4096 from 512. > (commit 22242681 "MIPS: Extend COMMAND_LINE_SIZE") > > This cause warning if something like buf[CL_SIZE] was declared as a > local variable, for example in prom_init_cmdline() on some platforms. > > And since many Makefiles in arch/mips enables -Werror, this cause > build failure. > > How can we avoid this error? > > - do not use local array? (but dynamic allocation cannot be used in > such an early stage. static array?) > - are there any way to disable -Wframe-larger-than for the file or function? > - make COMMAND_LINE_SIZE customizable? > - use non default CONFIG_FRAME_WARN? > > Any comments or suggestions? does "static" helps this problem? Regards, Wu Zhangjin ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: COMMAND_LINE_SIZE and CONFIG_FRAME_WARN 2009-11-06 16:08 COMMAND_LINE_SIZE and CONFIG_FRAME_WARN Atsushi Nemoto 2009-11-06 16:10 ` Atsushi Nemoto 2009-11-06 16:18 ` Wu Zhangjin @ 2009-11-06 16:22 ` Dmitri Vorobiev 2009-11-06 16:34 ` Dmitri Vorobiev 2009-11-06 16:34 ` Maciej W. Rozycki 3 siblings, 1 reply; 15+ messages in thread From: Dmitri Vorobiev @ 2009-11-06 16:22 UTC (permalink / raw) To: Atsushi Nemoto; +Cc: linux-mips On Fri, Nov 6, 2009 at 6:08 PM, Atsushi Nemoto <anemo@mba.ocn.ne.jp> wrote: > Recently COMMAND_LINE_SIZE (CL_SIZE) was extended to 4096 from 512. > (commit 22242681 "MIPS: Extend COMMAND_LINE_SIZE") > > This cause warning if something like buf[CL_SIZE] was declared as a > local variable, for example in prom_init_cmdline() on some platforms. > > And since many Makefiles in arch/mips enables -Werror, this cause > build failure. > > How can we avoid this error? > > - do not use local array? (but dynamic allocation cannot be used in > such an early stage. static array?) Maybe a static array marked with __initdata? Dmitri ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: COMMAND_LINE_SIZE and CONFIG_FRAME_WARN 2009-11-06 16:22 ` Dmitri Vorobiev @ 2009-11-06 16:34 ` Dmitri Vorobiev 2009-11-06 16:44 ` Dmitri Vorobiev 2009-11-06 16:44 ` David Daney 0 siblings, 2 replies; 15+ messages in thread From: Dmitri Vorobiev @ 2009-11-06 16:34 UTC (permalink / raw) To: Atsushi Nemoto; +Cc: linux-mips On Fri, Nov 6, 2009 at 6:22 PM, Dmitri Vorobiev <dmitri.vorobiev@gmail.com> wrote: > On Fri, Nov 6, 2009 at 6:08 PM, Atsushi Nemoto <anemo@mba.ocn.ne.jp> wrote: >> Recently COMMAND_LINE_SIZE (CL_SIZE) was extended to 4096 from 512. >> (commit 22242681 "MIPS: Extend COMMAND_LINE_SIZE") >> >> This cause warning if something like buf[CL_SIZE] was declared as a >> local variable, for example in prom_init_cmdline() on some platforms. >> >> And since many Makefiles in arch/mips enables -Werror, this cause >> build failure. >> >> How can we avoid this error? >> >> - do not use local array? (but dynamic allocation cannot be used in >> such an early stage. static array?) > > Maybe a static array marked with __initdata? Also, I just thought that maybe it's possible to use a c99 variable-length array here? Like this: int n = COMMAND_LINE_SIZE; char buf[n]; This way, we don't put yet another variable in the .init.data section, unlike with the static array solution. However, this is totally untested, just a thought... Dmitri > > Dmitri > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: COMMAND_LINE_SIZE and CONFIG_FRAME_WARN 2009-11-06 16:34 ` Dmitri Vorobiev @ 2009-11-06 16:44 ` Dmitri Vorobiev 2009-11-06 16:44 ` David Daney 1 sibling, 0 replies; 15+ messages in thread From: Dmitri Vorobiev @ 2009-11-06 16:44 UTC (permalink / raw) To: Atsushi Nemoto; +Cc: linux-mips On Fri, Nov 6, 2009 at 6:34 PM, Dmitri Vorobiev <dmitri.vorobiev@gmail.com> wrote: > On Fri, Nov 6, 2009 at 6:22 PM, Dmitri Vorobiev > <dmitri.vorobiev@gmail.com> wrote: >> On Fri, Nov 6, 2009 at 6:08 PM, Atsushi Nemoto <anemo@mba.ocn.ne.jp> wrote: >>> Recently COMMAND_LINE_SIZE (CL_SIZE) was extended to 4096 from 512. >>> (commit 22242681 "MIPS: Extend COMMAND_LINE_SIZE") >>> >>> This cause warning if something like buf[CL_SIZE] was declared as a >>> local variable, for example in prom_init_cmdline() on some platforms. >>> >>> And since many Makefiles in arch/mips enables -Werror, this cause >>> build failure. >>> >>> How can we avoid this error? >>> >>> - do not use local array? (but dynamic allocation cannot be used in >>> such an early stage. static array?) >> >> Maybe a static array marked with __initdata? > > Also, I just thought that maybe it's possible to use a c99 > variable-length array here? Like this: > > int n = COMMAND_LINE_SIZE; > char buf[n]; > > This way, we don't put yet another variable in the .init.data section, > unlike with the static array solution. > > However, this is totally untested, just a thought... Just tried the variable-length array option, proves to be working: dmvo@cipher:/tmp$ cat c.c f() { char buf[4096]; } dmvo@cipher:/tmp$ cc -c -Wframe-larger-than=1024 c.c c.c: In function ‘f’: c.c:4: warning: the frame size of 4112 bytes is larger than 1024 bytes dmvo@cipher:/tmp$ cat d.c f() { int n = 4096; char buf1[n]; } dmvo@cipher:/tmp$ cc -c -Wframe-larger-than=1024 d.c Dmitri ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: COMMAND_LINE_SIZE and CONFIG_FRAME_WARN 2009-11-06 16:34 ` Dmitri Vorobiev 2009-11-06 16:44 ` Dmitri Vorobiev @ 2009-11-06 16:44 ` David Daney 2009-11-06 17:07 ` Dmitri Vorobiev 2009-11-06 17:09 ` Maciej W. Rozycki 1 sibling, 2 replies; 15+ messages in thread From: David Daney @ 2009-11-06 16:44 UTC (permalink / raw) To: Dmitri Vorobiev; +Cc: Atsushi Nemoto, linux-mips Dmitri Vorobiev wrote: > On Fri, Nov 6, 2009 at 6:22 PM, Dmitri Vorobiev > <dmitri.vorobiev@gmail.com> wrote: >> On Fri, Nov 6, 2009 at 6:08 PM, Atsushi Nemoto <anemo@mba.ocn.ne.jp> wrote: >>> Recently COMMAND_LINE_SIZE (CL_SIZE) was extended to 4096 from 512. >>> (commit 22242681 "MIPS: Extend COMMAND_LINE_SIZE") >>> >>> This cause warning if something like buf[CL_SIZE] was declared as a >>> local variable, for example in prom_init_cmdline() on some platforms. >>> >>> And since many Makefiles in arch/mips enables -Werror, this cause >>> build failure. >>> >>> How can we avoid this error? >>> >>> - do not use local array? (but dynamic allocation cannot be used in >>> such an early stage. static array?) >> Maybe a static array marked with __initdata? > > Also, I just thought that maybe it's possible to use a c99 > variable-length array here? Like this: > > int n = COMMAND_LINE_SIZE; > char buf[n]; > > This way, we don't put yet another variable in the .init.data section, > unlike with the static array solution. > > However, this is totally untested, just a thought... > It depends on your concerns. You are still using 4096 bytes of stack, but you are trying to trick the compiler into not warning. If you think the warning is bogus, you should remove it for all code, not just this file. If you think the warning is valid, then you should fix the code so that it doesn't use as much stack space. David Daney ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: COMMAND_LINE_SIZE and CONFIG_FRAME_WARN 2009-11-06 16:44 ` David Daney @ 2009-11-06 17:07 ` Dmitri Vorobiev 2009-11-06 17:16 ` Maciej W. Rozycki 2009-11-06 17:09 ` Maciej W. Rozycki 1 sibling, 1 reply; 15+ messages in thread From: Dmitri Vorobiev @ 2009-11-06 17:07 UTC (permalink / raw) To: David Daney; +Cc: Atsushi Nemoto, linux-mips On Fri, Nov 6, 2009 at 6:44 PM, David Daney <ddaney@caviumnetworks.com> wrote: > Dmitri Vorobiev wrote: >> >> On Fri, Nov 6, 2009 at 6:22 PM, Dmitri Vorobiev >> <dmitri.vorobiev@gmail.com> wrote: >>> >>> On Fri, Nov 6, 2009 at 6:08 PM, Atsushi Nemoto <anemo@mba.ocn.ne.jp> >>> wrote: >>>> >>>> Recently COMMAND_LINE_SIZE (CL_SIZE) was extended to 4096 from 512. >>>> (commit 22242681 "MIPS: Extend COMMAND_LINE_SIZE") >>>> >>>> This cause warning if something like buf[CL_SIZE] was declared as a >>>> local variable, for example in prom_init_cmdline() on some platforms. >>>> >>>> And since many Makefiles in arch/mips enables -Werror, this cause >>>> build failure. >>>> >>>> How can we avoid this error? >>>> >>>> - do not use local array? (but dynamic allocation cannot be used in >>>> such an early stage. static array?) >>> >>> Maybe a static array marked with __initdata? >> >> Also, I just thought that maybe it's possible to use a c99 >> variable-length array here? Like this: >> >> int n = COMMAND_LINE_SIZE; >> char buf[n]; >> >> This way, we don't put yet another variable in the .init.data section, >> unlike with the static array solution. >> >> However, this is totally untested, just a thought... >> > > It depends on your concerns. You are still using 4096 bytes of stack, but > you are trying to trick the compiler into not warning. > > If you think the warning is bogus, you should remove it for all code, not > just this file. If you think the warning is valid, then you should fix the > code so that it doesn't use as much stack space. Frankly, I don't think that the warning is bogus, especially if we're talking about the case of the 4K page and 32-bit kernel, and I started thinking htat probably the static array solution would be the safest bet here. Dmitri ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: COMMAND_LINE_SIZE and CONFIG_FRAME_WARN 2009-11-06 17:07 ` Dmitri Vorobiev @ 2009-11-06 17:16 ` Maciej W. Rozycki 2009-11-06 17:23 ` Dmitri Vorobiev 0 siblings, 1 reply; 15+ messages in thread From: Maciej W. Rozycki @ 2009-11-06 17:16 UTC (permalink / raw) To: Dmitri Vorobiev; +Cc: David Daney, Atsushi Nemoto, linux-mips On Fri, 6 Nov 2009, Dmitri Vorobiev wrote: > > It depends on your concerns. You are still using 4096 bytes of stack, but > > you are trying to trick the compiler into not warning. > > > > If you think the warning is bogus, you should remove it for all code, not > > just this file. If you think the warning is valid, then you should fix the > > code so that it doesn't use as much stack space. > > Frankly, I don't think that the warning is bogus, especially if we're > talking about the case of the 4K page and 32-bit kernel, and I started > thinking htat probably the static array solution would be the safest > bet here. KSEG space is not paged, so who cares about the page size? You're not making additional stack page allocations, although you can overflow the space available at some point (but that's avoided if you know a priori your backtrace is not going to be deep). Static allocation has its drawbacks, for example it takes storage space (if it's initialised data) or memory space (if it's BSS) indefinitely. Maciej ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: COMMAND_LINE_SIZE and CONFIG_FRAME_WARN 2009-11-06 17:16 ` Maciej W. Rozycki @ 2009-11-06 17:23 ` Dmitri Vorobiev 2009-11-06 17:30 ` Maciej W. Rozycki 0 siblings, 1 reply; 15+ messages in thread From: Dmitri Vorobiev @ 2009-11-06 17:23 UTC (permalink / raw) To: Maciej W. Rozycki; +Cc: David Daney, Atsushi Nemoto, linux-mips On Fri, Nov 6, 2009 at 7:16 PM, Maciej W. Rozycki <macro@linux-mips.org> wrote: > On Fri, 6 Nov 2009, Dmitri Vorobiev wrote: > >> > It depends on your concerns. You are still using 4096 bytes of stack, but >> > you are trying to trick the compiler into not warning. >> > >> > If you think the warning is bogus, you should remove it for all code, not >> > just this file. If you think the warning is valid, then you should fix the >> > code so that it doesn't use as much stack space. >> >> Frankly, I don't think that the warning is bogus, especially if we're >> talking about the case of the 4K page and 32-bit kernel, and I started >> thinking htat probably the static array solution would be the safest >> bet here. > > KSEG space is not paged, so who cares about the page size? You're not > making additional stack page allocations, although you can overflow the > space available at some point (but that's avoided if you know a priori > your backtrace is not going to be deep). Static allocation has its > drawbacks, for example it takes storage space (if it's initialised data) > or memory space (if it's BSS) indefinitely. Thanks for the explanation. Then a variable-size array, I guess. Dmitri > > Maciej > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: COMMAND_LINE_SIZE and CONFIG_FRAME_WARN 2009-11-06 17:23 ` Dmitri Vorobiev @ 2009-11-06 17:30 ` Maciej W. Rozycki 2009-11-06 18:17 ` Dmitri Vorobiev 0 siblings, 1 reply; 15+ messages in thread From: Maciej W. Rozycki @ 2009-11-06 17:30 UTC (permalink / raw) To: Dmitri Vorobiev; +Cc: David Daney, Atsushi Nemoto, linux-mips On Fri, 6 Nov 2009, Dmitri Vorobiev wrote: > > KSEG space is not paged, so who cares about the page size? You're not > > making additional stack page allocations, although you can overflow the > > space available at some point (but that's avoided if you know a priori > > your backtrace is not going to be deep). Static allocation has its > > drawbacks, for example it takes storage space (if it's initialised data) > > or memory space (if it's BSS) indefinitely. > > Thanks for the explanation. Then a variable-size array, I guess. Note that MIPS is at an advantage here and other architectures may have to page the kernel space, so the observation is valid for our platform code only -- for generic code (anything that goes outside arch/mips) you may have to change the assumptions. Maciej ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: COMMAND_LINE_SIZE and CONFIG_FRAME_WARN 2009-11-06 17:30 ` Maciej W. Rozycki @ 2009-11-06 18:17 ` Dmitri Vorobiev 2009-11-07 17:19 ` Atsushi Nemoto 0 siblings, 1 reply; 15+ messages in thread From: Dmitri Vorobiev @ 2009-11-06 18:17 UTC (permalink / raw) To: Maciej W. Rozycki; +Cc: David Daney, Atsushi Nemoto, linux-mips On Fri, Nov 6, 2009 at 7:30 PM, Maciej W. Rozycki <macro@linux-mips.org> wrote: > On Fri, 6 Nov 2009, Dmitri Vorobiev wrote: > >> > KSEG space is not paged, so who cares about the page size? You're not >> > making additional stack page allocations, although you can overflow the >> > space available at some point (but that's avoided if you know a priori >> > your backtrace is not going to be deep). Static allocation has its >> > drawbacks, for example it takes storage space (if it's initialised data) >> > or memory space (if it's BSS) indefinitely. >> >> Thanks for the explanation. Then a variable-size array, I guess. > > Note that MIPS is at an advantage here and other architectures may have > to page the kernel space, so the observation is valid for our platform > code only -- for generic code (anything that goes outside arch/mips) you > may have to change the assumptions. I believe that Atsushi-san was talking about the MIPS code only. Indeed, he mentioned CL_SIZE, which used to be a MIPS-specific alias to COMMAND_LINE_SIZE. Dmitri > > Maciej > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: COMMAND_LINE_SIZE and CONFIG_FRAME_WARN 2009-11-06 18:17 ` Dmitri Vorobiev @ 2009-11-07 17:19 ` Atsushi Nemoto 0 siblings, 0 replies; 15+ messages in thread From: Atsushi Nemoto @ 2009-11-07 17:19 UTC (permalink / raw) To: dmitri.vorobiev; +Cc: macro, ddaney, linux-mips On Fri, 6 Nov 2009 20:17:06 +0200, Dmitri Vorobiev <dmitri.vorobiev@gmail.com> wrote: > I believe that Atsushi-san was talking about the MIPS code only. > Indeed, he mentioned CL_SIZE, which used to be a MIPS-specific alias > to COMMAND_LINE_SIZE. Yes, and I think static array is safest option now. MIPS might be able to use large stack on early bootstrap stage, but this assumption looks slightly fragile for me. And excessive zero-initialized __initdata size will not be a problem especially if vmlinux is compressed. Thank you everyone, I will post a patch soon. --- Atsushi Nemoto ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: COMMAND_LINE_SIZE and CONFIG_FRAME_WARN 2009-11-06 16:44 ` David Daney 2009-11-06 17:07 ` Dmitri Vorobiev @ 2009-11-06 17:09 ` Maciej W. Rozycki 1 sibling, 0 replies; 15+ messages in thread From: Maciej W. Rozycki @ 2009-11-06 17:09 UTC (permalink / raw) To: David Daney; +Cc: Dmitri Vorobiev, Atsushi Nemoto, linux-mips On Fri, 6 Nov 2009, David Daney wrote: > It depends on your concerns. You are still using 4096 bytes of stack, > but you are trying to trick the compiler into not warning. > > If you think the warning is bogus, you should remove it for all code, > not just this file. If you think the warning is valid, then you should > fix the code so that it doesn't use as much stack space. My understanding is the option is for detecting unintended excessive use of stack space. If a place is known to require more space, it is justified and harmless (such as in an early bootstrap call), then I see no reason to forbid it or to imply it should be allowed globally then. Note that stack space of 4096 bytes required by a single call is functionally equivalent to four nested calls requiring 1024 bytes each, so from the practical point of view they are equivalent and during kernel startup we may know that nesting is less extensive than, say, when a syscall or an interrupt handler is being executed, where such stack consumption would be of much more concern. Maciej ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: COMMAND_LINE_SIZE and CONFIG_FRAME_WARN 2009-11-06 16:08 COMMAND_LINE_SIZE and CONFIG_FRAME_WARN Atsushi Nemoto ` (2 preceding siblings ...) 2009-11-06 16:22 ` Dmitri Vorobiev @ 2009-11-06 16:34 ` Maciej W. Rozycki 3 siblings, 0 replies; 15+ messages in thread From: Maciej W. Rozycki @ 2009-11-06 16:34 UTC (permalink / raw) To: Atsushi Nemoto; +Cc: linux-mips On Sat, 7 Nov 2009, Atsushi Nemoto wrote: > Recently COMMAND_LINE_SIZE (CL_SIZE) was extended to 4096 from 512. > (commit 22242681 "MIPS: Extend COMMAND_LINE_SIZE") > > This cause warning if something like buf[CL_SIZE] was declared as a > local variable, for example in prom_init_cmdline() on some platforms. > > And since many Makefiles in arch/mips enables -Werror, this cause > build failure. > > How can we avoid this error? > > - do not use local array? (but dynamic allocation cannot be used in > such an early stage. static array?) > - are there any way to disable -Wframe-larger-than for the file or function? > - make COMMAND_LINE_SIZE customizable? > - use non default CONFIG_FRAME_WARN? > > Any comments or suggestions? Use static storage and mark it initdata? You can certainly override -Wframe-larger-than in per-object CFLAGS too. You might also be able to use __builtin_alloca(), but this sounds like a shaky ground. ;) Maciej ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2009-11-07 17:19 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-11-06 16:08 COMMAND_LINE_SIZE and CONFIG_FRAME_WARN Atsushi Nemoto 2009-11-06 16:10 ` Atsushi Nemoto 2009-11-06 16:18 ` Wu Zhangjin 2009-11-06 16:22 ` Dmitri Vorobiev 2009-11-06 16:34 ` Dmitri Vorobiev 2009-11-06 16:44 ` Dmitri Vorobiev 2009-11-06 16:44 ` David Daney 2009-11-06 17:07 ` Dmitri Vorobiev 2009-11-06 17:16 ` Maciej W. Rozycki 2009-11-06 17:23 ` Dmitri Vorobiev 2009-11-06 17:30 ` Maciej W. Rozycki 2009-11-06 18:17 ` Dmitri Vorobiev 2009-11-07 17:19 ` Atsushi Nemoto 2009-11-06 17:09 ` Maciej W. Rozycki 2009-11-06 16:34 ` Maciej W. Rozycki
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.