* Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected
From: Bernd Petrovitsch @ 2008-08-27 8:34 UTC (permalink / raw)
To: Parag Warudkar
Cc: Linus Torvalds, Adrian Bunk, Rusty Russell, Alan D. Brunelle,
Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List,
Andrew Morton, Arjan van de Ven, Ingo Molnar, linux-embedded
In-Reply-To: <f7848160808261554j2f4eaaa6i1ee8801ae75ca7bf@mail.gmail.com>
On Tue, 2008-08-26 at 18:54 -0400, Parag Warudkar wrote:
> On Tue, Aug 26, 2008 at 5:04 PM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>
> > And embedded people (the ones that might care about 1% code size) are the
> > ones that would also want smaller stacks even more!
>
> This is something I never understood - embedded devices are not going
> to run more than a few processes and 4K*(Few Processes)
> IMHO is not worth a saving now a days even in embedded world given
> falling memory prices. Or do I misunderstand?
Falling prices are no reason to increase the amount of available RAM (or
other hardware).
Especially if you (intend to) build >1E5 devices - where every Euro
counts.
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
^ permalink raw reply
* Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected
From: Bernd Petrovitsch @ 2008-08-27 8:44 UTC (permalink / raw)
To: Parag Warudkar
Cc: Greg Ungerer, Linus Torvalds, Adrian Bunk, Rusty Russell,
Alan D. Brunelle, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Andrew Morton, Arjan van de Ven, Ingo Molnar,
linux-embedded
In-Reply-To: <f7848160808261916x6e2a3abfj2c28fa665da792b4@mail.gmail.com>
On Tue, 2008-08-26 at 22:16 -0400, Parag Warudkar wrote:
[...]
> Well, sure - but the industry as a whole seems to have gone the other
"The industry as a whole" doesn't exist on that low level. You can't
compare the laptop and/or desktop computer market (where one may buy
today hardware that runs in 3 years with the next generation/release of
the OS and applications) with the e.g. "WLAN router" market where - from
the commercial point of view - every Euro counts (and where the
requirements for the lifetime of the device are long frozen before the
thing gets in a shop).
> way - do more with more at the similar or lower price points!
> By that definition of less is better we should try and make the kernel
> memory pageable (or has someone already done that?) - Windows does it,
That doesn't help as in really small devices (like WLAN routers, cable
modems, etc.) you run without any means of paging/swapping. And even
binaries/read-only files are not necessarily executable in place (but
must be loaded into RAM). So you can't flush these pages.
And pageable kernel memory doesn't come for free - even if one only
counts the increased code and it's complexity.
> by default ;)
Which is more a sign that it is probably a very bad idea.
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
^ permalink raw reply
* Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected
From: Bernd Petrovitsch @ 2008-08-27 9:00 UTC (permalink / raw)
To: Parag Warudkar
Cc: Linus Torvalds, Adrian Bunk, Rusty Russell, Alan D. Brunelle,
Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List,
Andrew Morton, Arjan van de Ven, Ingo Molnar, linux-embedded
In-Reply-To: <f7848160808261758q7b84aab1m188c1ebb59304818@mail.gmail.com>
On Tue, 2008-08-26 at 20:58 -0400, Parag Warudkar wrote:
[...]
> The savings part -financial ones- are not always realizable with the
> way memory is priced/sized/fitted.
> Savings in few Mb of Kernel stack are not necessarily going to allow
> getting rid of a single memory chip of 64M or so.
No, but you can put an additional service(s) on it and sales people have
one (or two or ....) line more for their sales brochures.
> Either that or embedded manufacturing/configurations are different
> than the desktop world.
They are different. Think of running the complete system acting as a
bridge, router and/or firewall (Kernel early 2.4 though) from 4MB flash
in 32MB RAM and - listing the outside visible services - having a
command-line interface, web-GUI (implying a http server) and and a
(net-)SNMP agent on it.
Running a glibc without thread support is win there (implying that there
is no thread support available on that device).
> (If my device has 2 memory slots and my user space requires 100Mb
> including kernel memory - I anyways have to put in 64Mx2 there to take
> advantage of mass manufactured, general purpose memory - so no big
> deal if I saved 1.2Mb in Kernel stack or not. And savings of 64Mb
> Kernel memory are not feasible anyways to allow user space to work
> with 64Mb.)
As soon as product management realizes that there is space left on the
device, they get new ideas and/or customer requirements to run more
services on that device.
> On the other hand reducing user space memory usage on those devices
> (not counting savings from kernel stack size) is a way more attractive
> option.
There is no question if save space here or there. You save it - sooner
or later - on all fronts. Period.
> And although you said in your later reply that Linux x86 with 4K
> stacks should be more than usable - my experiences running a untainted
> desktop/file server with 4K stack have been always disastrous XFS or
> not. It _might_ work for some well defined workloads but you would
> not want to risk 4K stacks otherwise.
The embedded world of really small devices usually doesn't run XFS (or
ext? or reiser* of jfs or NFS or ...) or stacks block devices on files
or .....
> I understand the having 4K stack option as a non-default for very
> specific workloads is a good idea but apart from that I think no one
> else seems to bother with reducing stack sizes (by no one I mean other
> OSes.)
They probably gave the idea pretty soon because you need to
rework/improve large parts of the kernel + drivers (and that has two
major problems - it consumes a lot of man power for "no new features and
everything must be completely tested again"[0] and it adds new risks).
And that is practically impossible if one sells "stable driver APIs" for
3rd party (commercial) drivers because these must be changed too.
Bernd
[0]: Let alone if you (or your customers) need certificates from some
governmental agencys.
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
^ permalink raw reply
* Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected
From: Arjan van de Ven @ 2008-08-27 10:58 UTC (permalink / raw)
To: Paul Mackerras
Cc: Linus Torvalds, Parag Warudkar, Adrian Bunk, Rusty Russell,
Alan D. Brunelle, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Andrew Morton, Ingo Molnar,
linux-embedded-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <18612.60878.887716.452936-nUko2b1QN/1kfgV4h6NXRTJtLkR7yuzc@public.gmane.org>
Paul Mackerras wrote:
> Linus Torvalds writes:
>
>> 4kB used to be the _only_ choice. And no, there weren't even irq stacks.
>> So that 4kB was not just the whole kernel call-chain, it was also all the
>> irq nesting above it.
>
> I think your memory is failing you. In 2.4 and earlier, the kernel
> stack was 8kB minus the size of the task_struct, which sat at the
> start of the 8kB. For instance, from include/asm-i386/processor.h for
> 2.4.29:
but was shared with interrupts; so out of the 6Kb left, you had still really only 4Kb for user context stack
^ permalink raw reply
* Re: "kernel access of bad area" while accessing flash
From: Josh Boyer @ 2008-08-27 11:33 UTC (permalink / raw)
To: Fundu; +Cc: linux embedded
In-Reply-To: <425469.77736.qm@web63401.mail.re1.yahoo.com>
On Tue, Aug 26, 2008 at 08:13:39PM -0700, Fundu wrote:
>I have a PPC440GX based board.
>
>Do I need to reinitialize Peripheral Bank Configuration Registers (EBC0_B0CR-EBC0_B7CR) from the kernel ?
>I'm quite sure that we don't, but just want to make sure. Because the problem
>that i'm seeing strongly suggest that it's probably not accessible.
Typically not. The kernel tends to rely on the EBC registers being properly
programmed by the bootloader/firmware for the devices contained in it's banks.
>Here's the problem, i'm getting "kernel access of bad
> area" when i erase any of the upper 64mb out of 128mb flash region, surprisingly i can easily erase (all of the flash) from u-boot. which makes me ask the earlier question.
>
That sounds more like a mapping issue than an EBC config issue. Make sure
the kernel is calling ioremap on the entire flash memory region.
josh
^ permalink raw reply
* Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected
From: Adrian Bunk @ 2008-08-27 11:58 UTC (permalink / raw)
To: Linus Torvalds
Cc: Rusty Russell, Alan D. Brunelle, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Andrew Morton,
Arjan van de Ven, Ingo Molnar,
linux-embedded-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <alpine.LFD.1.10.0808261726560.3363-nfNrOhbfy2R17+2ddN/4kux8cNe9sq/dYPYVAmT7z5s@public.gmane.org>
On Tue, Aug 26, 2008 at 05:28:37PM -0700, Linus Torvalds wrote:
>
>
> On Wed, 27 Aug 2008, Adrian Bunk wrote:
> >
> > When did we get callpaths like like nfs+xfs+md+scsi reliably
> > working with 4kB stacks on x86-32?
>
> XFS may never have been usable, but the rest, sure.
>
> And you seem to be making this whole argument an excuse to SUCK, adn an
> excuse to let gcc crap even more on our stack space.
>
> Why?
>
> Why aren't you saying that we should be able to do better? Instead, you
> seem to asking us to do even worse than we do now?
My main point is:
- getting 4kB stacks working reliably is a hard task
- having an eye on gcc increasing the stack usage, and fixing it if
required, is relatively easy
If we should be able to do better at getting (and keeping) 4kB stacks
working, then coping with possible inlining problems caused by gcc
should not be a big problem for us.
> Linus
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected
From: Adrian Bunk @ 2008-08-27 11:58 UTC (permalink / raw)
To: Linus Torvalds
Cc: Parag Warudkar, Rusty Russell, Alan D. Brunelle,
Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List,
Andrew Morton, Arjan van de Ven, Ingo Molnar, linux-embedded
In-Reply-To: <alpine.LFD.1.10.0808261837530.3363@nehalem.linux-foundation.org>
On Tue, Aug 26, 2008 at 06:49:19PM -0700, Linus Torvalds wrote:
>...
> But part of it is definitely gcc. Some versions of gcc used to be
> absolutely _horrid_ when it came to stack usage, especially with some
> flags, and especially with the crazy inlining that module-at-a-time
> caused.
>...
That was gcc 3.4.
And due to that we disable unit-at-a-time for gcc 3.4 on 32bit x86.
> Linus
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected
From: Parag Warudkar @ 2008-08-27 12:52 UTC (permalink / raw)
To: Alan Cox
Cc: Adrian Bunk, Linus Torvalds, Rusty Russell, Alan D. Brunelle,
Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List,
Andrew Morton, Arjan van de Ven, Ingo Molnar, linux-embedded
In-Reply-To: <20080827092528.780916bd@lxorguk.ukuu.org.uk>
On Wed, Aug 27, 2008 at 4:25 AM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> You have a good point that aiming at 4kB makes 8kB a very safe choice.
>
> Not really no - we use separate IRQ stacks in 4K but not 8K mode on
> x86-32. That means you've actually got no more space if you are unlucky
> with the timing of events. The 8K mode is merely harder to debug.
>
By your logic though, XFS on x86 should work fine with 4K stacks -
many will attest that it does not and blows up due to stack issues.
I have first hand experiences of things blowing up with deep call
chains when using 4K stacks where 8K worked just fine on same
workload.
So there is definitely some other problem with 4K stacks.
Thanks
Parag
^ permalink raw reply
* Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected
From: Parag Warudkar @ 2008-08-27 12:56 UTC (permalink / raw)
To: Bernd Petrovitsch
Cc: Linus Torvalds, Adrian Bunk, Rusty Russell, Alan D. Brunelle,
Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List,
Andrew Morton, Arjan van de Ven, Ingo Molnar,
linux-embedded-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1219827609.30209.29.camel-7sPfb3biEqGJZy4MaDjwDw@public.gmane.org>
On Wed, Aug 27, 2008 at 5:00 AM, Bernd Petrovitsch <bernd-GBwJepH+xoVeoWH0uzbU5w@public.gmane.org> wrote:
>
> They probably gave the idea pretty soon because you need to
> rework/improve large parts of the kernel + drivers (and that has two
> major problems - it consumes a lot of man power for "no new features and
> everything must be completely tested again"[0] and it adds new risks).
> And that is practically impossible if one sells "stable driver APIs" for
> 3rd party (commercial) drivers because these must be changed too.
>
But not many embedded Linux arches support 4K stacks like Adrian
pointed out earlier.
So the same (lot of man power requirement) would apply to Linux.
Sure it will be good - but how reasonable it is to attempt it and how
reliably it will work under all conceived loads - those are the
questions.
Thanks
Parag
^ permalink raw reply
* Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected
From: Bernd Petrovitsch @ 2008-08-27 13:17 UTC (permalink / raw)
To: Parag Warudkar
Cc: Linus Torvalds, Adrian Bunk, Rusty Russell, Alan D. Brunelle,
Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List,
Andrew Morton, Arjan van de Ven, Ingo Molnar, linux-embedded
In-Reply-To: <f7848160808270556q54c36270ye6a465d2ca123cc@mail.gmail.com>
On Wed, 2008-08-27 at 08:56 -0400, Parag Warudkar wrote:
> On Wed, Aug 27, 2008 at 5:00 AM, Bernd Petrovitsch <bernd@firmix.at> wrote:
> > They probably gave the idea pretty soon because you need to
> > rework/improve large parts of the kernel + drivers (and that has two
> > major problems - it consumes a lot of man power for "no new features and
> > everything must be completely tested again"[0] and it adds new risks).
> > And that is practically impossible if one sells "stable driver APIs" for
> > 3rd party (commercial) drivers because these must be changed too.
>
> But not many embedded Linux arches support 4K stacks like Adrian
What is an "embedded Linux arch"?
Personally I encountered i386, ARM, MIPS and PPC in the embedded world.
> pointed out earlier.
> So the same (lot of man power requirement) would apply to Linux.
Of course. Look at the amount of work done by lots of people in that
area (including stack frame size reductions) and on-going discussions.
> Sure it will be good - but how reasonable it is to attempt it and how
> reliably it will work under all conceived loads - those are the
> questions.
If you "develop" an embedded system (which is partly system integration
of existing apps) to be installed in the field, you don't have that many
conceivable work loads compared to a desktop/server system. And you have
a fixed list of drivers and applications.
A usual approach is to run stress tests on several (or all)
subsystems/services/... in parallel and if the device survives it
functioning correctly, it is at least good enough.
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
^ permalink raw reply
* Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected
From: Alan Cox @ 2008-08-27 13:21 UTC (permalink / raw)
To: Parag Warudkar
Cc: Adrian Bunk, Linus Torvalds, Rusty Russell, Alan D. Brunelle,
Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List,
Andrew Morton, Arjan van de Ven, Ingo Molnar,
linux-embedded-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <f7848160808270552u2ee66167x912a68e0bf8b25bf-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
> By your logic though, XFS on x86 should work fine with 4K stacks -
> many will attest that it does not and blows up due to stack issues.
>
> I have first hand experiences of things blowing up with deep call
> chains when using 4K stacks where 8K worked just fine on same
> workload.
>
> So there is definitely some other problem with 4K stacks.
Nothing of the sort. If it blows up with a 4K stack it will almost
certainly blow up with an 8K stack *eventually* - when a heavy stack usage
coincides with a heavy stack using IRQ handler.
You won't catch it in simple testing, you won't catch it in trivial
simulation and it'll be incredibly hard to reproduce. Not the kind of bug
you want in a production system really. IRQ stacks make things much more
predictable.
Alan
^ permalink raw reply
* Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected
From: Linus Torvalds @ 2008-08-27 15:18 UTC (permalink / raw)
To: Paul Mackerras
Cc: Parag Warudkar, Adrian Bunk, Rusty Russell, Alan D. Brunelle,
Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List,
Andrew Morton, Arjan van de Ven, Ingo Molnar, linux-embedded
In-Reply-To: <18612.60878.887716.452936@drongo.ozlabs.ibm.com>
On Wed, 27 Aug 2008, Paul Mackerras wrote:
>
> I think your memory is failing you. In 2.4 and earlier, the kernel
> stack was 8kB minus the size of the task_struct, which sat at the
> start of the 8kB.
Yup, you're right.
Linus
^ permalink raw reply
* Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected
From: Jamie Lokier @ 2008-08-27 15:48 UTC (permalink / raw)
To: Bernd Petrovitsch
Cc: Parag Warudkar, Linus Torvalds, Adrian Bunk, Rusty Russell,
Alan D. Brunelle, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Andrew Morton, Arjan van de Ven, Ingo Molnar,
linux-embedded-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1219843032.30209.51.camel-7sPfb3biEqGJZy4MaDjwDw@public.gmane.org>
Bernd Petrovitsch wrote:
> If you "develop" an embedded system (which is partly system integration
> of existing apps) to be installed in the field, you don't have that many
> conceivable work loads compared to a desktop/server system. And you have
> a fixed list of drivers and applications.
Hah! Not in my line of embedded device.
32MB no-MMU ARM boards which people run new things and attach new
devices to rather often - without making new hardware. Volume's too
low per individual application to get new hardware designed and made.
I'm seriously thinking of forwarding porting the 4 year old firmware
from 2.4.26 to 2.6.current, just to get new drivers and capabilities.
Backporting is tedious, so's feeling wretchedly far from the mainline
world.
> A usual approach is to run stress tests on several (or all)
> subsystems/services/... in parallel and if the device survives it
> functioning correctly, it is at least good enough.
Per application.
Some little devices run hundreds of different applications and
customers expect to customise, script themselves, and attach different
devices (over USB). The next customer in the chain expects the bits
you supplied to work in a variety of unexpected situations, even when
you advise that it probably won't do that.
Much like desktop/server Linux, but on a small device where silly
little things like 'create a process' are a stress for the dear little
thing.
(My biggest lesson: insist on an MMU next time!)
-- Jamie
^ permalink raw reply
* Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected
From: Paul Mundt @ 2008-08-27 16:00 UTC (permalink / raw)
To: Adrian Bunk
Cc: Linus Torvalds, Rusty Russell, Alan D. Brunelle,
Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List,
Andrew Morton, Arjan van de Ven, Ingo Molnar,
linux-embedded-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20080827115829.GF11734-re2QNgSbS3j4D6uPqz5PAwR5/fbUUdgG@public.gmane.org>
On Wed, Aug 27, 2008 at 02:58:30PM +0300, Adrian Bunk wrote:
> On Tue, Aug 26, 2008 at 05:28:37PM -0700, Linus Torvalds wrote:
> > On Wed, 27 Aug 2008, Adrian Bunk wrote:
> > >
> > > When did we get callpaths like like nfs+xfs+md+scsi reliably
> > > working with 4kB stacks on x86-32?
> >
> > XFS may never have been usable, but the rest, sure.
> >
> > And you seem to be making this whole argument an excuse to SUCK, adn an
> > excuse to let gcc crap even more on our stack space.
> >
> > Why?
> >
> > Why aren't you saying that we should be able to do better? Instead, you
> > seem to asking us to do even worse than we do now?
>
> My main point is:
> - getting 4kB stacks working reliably is a hard task
> - having an eye on gcc increasing the stack usage, and fixing it if
> required, is relatively easy
>
> If we should be able to do better at getting (and keeping) 4kB stacks
> working, then coping with possible inlining problems caused by gcc
> should not be a big problem for us.
>
Out of the architectures you've mentioned for 4k stacks, they also tend
to do IRQ stacks, which is something you seem to have overlooked.
In addition to that, debugging the runaway stack users on 4k tends to be
easier anyways since you end up blowing the stack a lot sooner. On sh
we've had pretty good luck with it, though most of our users are using
fairly deterministic workloads and continually profiling the footprint.
Anything that runs away or uses an insane amount of stack space needs to
be fixed well before that anyways, so catching it sooner is always
preferable. I imagine the same case is true for m68knommu (even sans IRQ
stacks).
Things might be more sensitive on x86, but it's certainly not something
that's a huge problem for the various embedded platforms to wire up,
whether they want to go the IRQ stack route or not.
In any event, lack of support for something on embedded architectures in
the kernel is more often due to apathy/utter indifference on the part of
the architecture maintainer rather than being indicative of any intrinsic
difficulty in supporting the thing in question. Most new "features" on the
lesser maintained architectures tend to end up there either out of peer
pressure or copying-and-pasting accidents rather than any sort of design.
;-)
^ permalink raw reply
* Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected
From: Jamie Lokier @ 2008-08-27 16:21 UTC (permalink / raw)
To: Linus Torvalds
Cc: Adrian Bunk, Rusty Russell, Alan D. Brunelle, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Andrew Morton,
Arjan van de Ven, Ingo Molnar, linux-embedded
In-Reply-To: <alpine.LFD.1.10.0808261332570.3363@nehalem.linux-foundation.org>
Linus Torvalds wrote:
> > Most LOCs of the kernel are not written by people like you or Al Viro or
> > David Miller, and the average kernel developer is unlikely to do it as
> > good as gcc.
>
> Sure. But we do have tools. We do have checkstack.pl, it's just that it
> hasn't been an issue in a long time, so I suspect many people didn't even
> _realize_ we have it, and I certainly can attest to the fact that even
> people who remember it - like me - don't actually tend to run it all that
> often.
Sounds like what's really desired here isn't more worry and
unpredictability, but for GCC+Binutils to gain the ability to
calculate the stack depth over all callchains (doesn't have to be
exact, just an upper bound; annotate recursions) in a way that's good
enough to do on every compile, complain if a depth is exceeded
statically (or it can't be proven), and to gain the
architecture-independent option "optimise to reduce stack usage".
> > BTW:
> > I just ran checkstack on a (roughly) allyesconfig kernel, and we have a
> > new driver that allocates "unsigned char recvbuf[1500];" on the stack...
>
> Yeah, it's _way_ too easy to do bad things.
In my userspace code, I have macros tmp_alloc and tmp_free. They must
be matched in the same function:
unsigned char * recvbuf = tmp_alloc(1500);
....
tmp_free(recvbuf);
When stack is plentiful, it maps to alloca() which is roughly
equivalent to using a stack variable.
When stack is constrained (as it is on my little devices), that maps
to xmalloc/free. The kernel equivalent would be kmalloc GFP_ATOMIC
(perhaps).
With different macros to mine, it may be possible to map small
fixed-size requests exactly onto local variables, and large ones to
kmalloc(). A stab at it (not tested):
#define LOCAL_ALLOC_THRESHOLD 128
#define LOCAL_ALLOC(type, ptr) \
__typeof__(type) __attribute__((__unused__)) ptr##_local_struct; \
__typeof__(type) * ptr = \
((__builtin_constant_p(sizeof(type)) \
&& sizeof(type) <= LOCAL_ALLOC_THRESHOLD) \
? &ptr##_local_struct : kmalloc(sizeof(type), GFP_ATOMIC))
#define LOCAL_FREE(ptr) \
((__builtin_constant_p(sizeof (*(ptr))) \
&& sizeof(*(ptr)) <= LOCAL_ALLOC_THRESHOLD) \
? (void) 0 : kfree(ptr))
Would that be useful in the kernel?
I'm thinking if it were a commonly used pattern for temporary buffers,
unknown structures and arrays of macro-determined size, the "new
driver" author would be less likely to accidentally drop a big object
on the stack.
Obviously it would be nicer for GCC to code such a thing
automatically, but that really is wishful thinking.
-- Jamie
^ permalink raw reply
* Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected
From: Parag Warudkar @ 2008-08-27 16:24 UTC (permalink / raw)
To: Alan Cox
Cc: Adrian Bunk, Linus Torvalds, Rusty Russell, Alan D. Brunelle,
Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List,
Andrew Morton, Arjan van de Ven, Ingo Molnar,
linux-embedded-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20080827142142.303cdba8-qBU/x9rampVanCEyBjwyrvXRex20P6io@public.gmane.org>
On Wed, Aug 27, 2008 at 9:21 AM, Alan Cox <alan-qBU/x9rampVanCEyBjwyrvXRex20P6io@public.gmane.org> wrote:
>> By your logic though, XFS on x86 should work fine with 4K stacks -
>> many will attest that it does not and blows up due to stack issues.
>>
>> I have first hand experiences of things blowing up with deep call
>> chains when using 4K stacks where 8K worked just fine on same
>> workload.
>>
>> So there is definitely some other problem with 4K stacks.
>
> Nothing of the sort. If it blows up with a 4K stack it will almost
> certainly blow up with an 8K stack *eventually* - when a heavy stack usage
> coincides with a heavy stack using IRQ handler.
>
> You won't catch it in simple testing, you won't catch it in trivial
> simulation and it'll be incredibly hard to reproduce. Not the kind of bug
> you want in a production system really. IRQ stacks make things much more
> predictable.
I see - so if I end up having a workload on 8k where heavy stack using
IRQs and deep kernel call chains come at the same time - even 8K will
blow up.
So 4K will blow too except that it doesn't require IRQs also to use
heavy stack, just XFS is good enough :)
It then seems like the IRQs using lot of stack is not so much of a
problem in the current kernel as much as deeper call chains and stack
usage of normal non-irq path code is.
So 8k makes it possible for the deeper call chains of non-irq path to
survive since they get better part of the 8K to themselves and IRQs
can do with less almost always.
At least that's what I can derive from the fact that we do not have
lots of reports of 8K stack blowing up.
Thanks
Parag
^ permalink raw reply
* Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected
From: Bernd Petrovitsch @ 2008-08-27 16:38 UTC (permalink / raw)
To: Jamie Lokier
Cc: Parag Warudkar, Linus Torvalds, Adrian Bunk, Rusty Russell,
Alan D. Brunelle, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Andrew Morton, Arjan van de Ven, Ingo Molnar,
linux-embedded
In-Reply-To: <20080827154805.GA25387@shareable.org>
On Wed, 2008-08-27 at 16:48 +0100, Jamie Lokier wrote:
> Bernd Petrovitsch wrote:
> > If you "develop" an embedded system (which is partly system integration
> > of existing apps) to be installed in the field, you don't have that many
> > conceivable work loads compared to a desktop/server system. And you have
> > a fixed list of drivers and applications.
>
> Hah! Not in my line of embedded device.
>
> 32MB no-MMU ARM boards which people run new things and attach new
> devices to rather often - without making new hardware. Volume's too
> low per individual application to get new hardware designed and made.
Yes, you may have several products on the same hardware with somewhat
differing requirements (or not). But that is much less than a general
purpose system IMHO.
> I'm seriously thinking of forwarding porting the 4 year old firmware
> from 2.4.26 to 2.6.current, just to get new drivers and capabilities.
That sounds reasonable (and I never meant maintaining the old system
infinitely. Actually once the thing is shipped it usually enters deep
maintenance mode and the next is more a fork from the old).
> Backporting is tedious, so's feeling wretchedly far from the mainline
> world.
ACK. But that also depends on amount local changes (and sorry, but not
all locally necessary patches would be accepted in mainline in any way).
> > A usual approach is to run stress tests on several (or all)
> > subsystems/services/... in parallel and if the device survives it
> > functioning correctly, it is at least good enough.
>
> Per application.
>
> Some little devices run hundreds of different applications and
> customers expect to customise, script themselves, and attach different
> devices (over USB). The next customer in the chain expects the bits
> you supplied to work in a variety of unexpected situations, even when
> you advise that it probably won't do that.
Basically their problem. Yes, "they" actually think they get a Linux
system where they can do everything and it simply works.
Oh, that's obviously not a usual "WLAN-router style" of product (where
you are not expected to actually login on a console or per ssh).
> Much like desktop/server Linux, but on a small device where silly
> little things like 'create a process' are a stress for the dear little
> thing.
>
> (My biggest lesson: insist on an MMU next time!)
ACK. We avoid MMU-less hardware too - especially since there is enough
hardware with a MMU around.
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
^ permalink raw reply
* Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected
From: Adrian Bunk @ 2008-08-27 17:35 UTC (permalink / raw)
To: Paul Mundt, Linus Torvalds, Rusty Russell, Alan D. Brunelle,
Rafael
In-Reply-To: <20080827160052.GA15968@linux-sh.org>
On Thu, Aug 28, 2008 at 01:00:52AM +0900, Paul Mundt wrote:
> On Wed, Aug 27, 2008 at 02:58:30PM +0300, Adrian Bunk wrote:
> > On Tue, Aug 26, 2008 at 05:28:37PM -0700, Linus Torvalds wrote:
> > > On Wed, 27 Aug 2008, Adrian Bunk wrote:
> > > >
> > > > When did we get callpaths like like nfs+xfs+md+scsi reliably
> > > > working with 4kB stacks on x86-32?
> > >
> > > XFS may never have been usable, but the rest, sure.
> > >
> > > And you seem to be making this whole argument an excuse to SUCK, adn an
> > > excuse to let gcc crap even more on our stack space.
> > >
> > > Why?
> > >
> > > Why aren't you saying that we should be able to do better? Instead, you
> > > seem to asking us to do even worse than we do now?
> >
> > My main point is:
> > - getting 4kB stacks working reliably is a hard task
> > - having an eye on gcc increasing the stack usage, and fixing it if
> > required, is relatively easy
> >
> > If we should be able to do better at getting (and keeping) 4kB stacks
> > working, then coping with possible inlining problems caused by gcc
> > should not be a big problem for us.
> >
> Out of the architectures you've mentioned for 4k stacks, they also tend
> to do IRQ stacks, which is something you seem to have overlooked.
No, I am aware of that, and on i386 IRQ stacks are only used with
4kB stacks.
On i386 it is effectively a step from 6kB to 4kB.
> In addition to that, debugging the runaway stack users on 4k tends to be
> easier anyways since you end up blowing the stack a lot sooner. On sh
> we've had pretty good luck with it, though most of our users are using
> fairly deterministic workloads and continually profiling the footprint.
> Anything that runs away or uses an insane amount of stack space needs to
> be fixed well before that anyways, so catching it sooner is always
> preferable. I imagine the same case is true for m68knommu (even sans IRQ
> stacks).
CONFIG_DEBUG_STACKOVERFLOW should give you the same information, and if
wanted with an arbitrary limit.
> Things might be more sensitive on x86, but it's certainly not something
> that's a huge problem for the various embedded platforms to wire up,
> whether they want to go the IRQ stack route or not.
How many platforms use 4kB stacks on sh?
Only 1 out of 34 defconfigs uses it.
Are there any numbers for real life usage.
> In any event, lack of support for something on embedded architectures in
> the kernel is more often due to apathy/utter indifference on the part of
> the architecture maintainer rather than being indicative of any intrinsic
> difficulty in supporting the thing in question. Most new "features" on the
> lesser maintained architectures tend to end up there either out of peer
> pressure or copying-and-pasting accidents rather than any sort of design.
> ;-)
arm or powerpc aren't exactly lesser maintained architectures.
4kB has shown to be a hard to achieve limit. After more than 4 years in
mainline being available on i386 there are still cases where 4kB are not
enough.
IMHO there seems to currently be a mismatch between it's maintainance
cost and the actual number of users. That's in my opinion the main
problem with it, no matter in which direction it gets resolved.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected
From: Jamie Lokier @ 2008-08-27 17:51 UTC (permalink / raw)
To: Bernd Petrovitsch
Cc: Parag Warudkar, Linus Torvalds, Adrian Bunk, Rusty Russell,
Alan D. Brunelle, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Andrew Morton, Arjan van de Ven, Ingo Molnar,
linux-embedded-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1219855121.30209.112.camel-7sPfb3biEqGJZy4MaDjwDw@public.gmane.org>
Bernd Petrovitsch wrote:
> > 32MB no-MMU ARM boards which people run new things and attach new
> > devices to rather often - without making new hardware. Volume's too
> > low per individual application to get new hardware designed and made.
>
> Yes, you may have several products on the same hardware with somewhat
> differing requirements (or not). But that is much less than a general
> purpose system IMHO.
It is, but the idea that small embedded systems go through a 'all
components are known, drivers are known, test and if it passes it's
shippable' does not always apply.
> > I'm seriously thinking of forwarding porting the 4 year old firmware
> > from 2.4.26 to 2.6.current, just to get new drivers and capabilities.
>
> That sounds reasonable (and I never meant maintaining the old system
> infinitely.
Sounds reasonable, but it's vetoed for anticipated time and cost,
compared with backporting on demand. Fair enough, since 2.6.current
doesn't support ARM no-MMU last I heard ('soon'?).
On the other hand, the 2.6 anti-fragmentation patches, including
latest SLUB stuff, ironically meant to help big machines, sound really
appealing for my current problem and totally unrealistic to
backport...
> ACK. We avoid MMU-less hardware too - especially since there is enough
> hardware with a MMU around.
I can't emphasise enough how much difference MMU makes to Linux userspace.
It's practically: MMU = standard Linux (with less RAM), have everything.
No-MMU = lots of familiar 'Linux' things not available or break.
-- Jamie
^ permalink raw reply
* Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected
From: Bernd Petrovitsch @ 2008-08-27 19:30 UTC (permalink / raw)
To: Jamie Lokier
Cc: Parag Warudkar, Linus Torvalds, Adrian Bunk, Rusty Russell,
Alan D. Brunelle, Rafael J. Wysocki, Linux Kernel Mailing List,
Kernel Testers List, Andrew Morton, Arjan van de Ven, Ingo Molnar,
linux-embedded
In-Reply-To: <20080827175152.GA27491@shareable.org>
On Mit, 2008-08-27 at 18:51 +0100, Jamie Lokier wrote:
> Bernd Petrovitsch wrote:
[...]
> It is, but the idea that small embedded systems go through a 'all
> components are known, drivers are known, test and if it passes it's
> shippable' does not always apply.
Not always but often enough. And yes, there is ARM-based embedded
hardware with 1GB Flash-RAM and 128MB RAM.
> > > I'm seriously thinking of forwarding porting the 4 year old firmware
> > > from 2.4.26 to 2.6.current, just to get new drivers and capabilities.
> >
> > That sounds reasonable (and I never meant maintaining the old system
> > infinitely.
>
> Sounds reasonable, but it's vetoed for anticipated time and cost,
That is to be expected;-)
[....]
> > ACK. We avoid MMU-less hardware too - especially since there is enough
> > hardware with a MMU around.
>
> I can't emphasise enough how much difference MMU makes to Linux userspace.
>
> It's practically: MMU = standard Linux (with less RAM), have everything.
> No-MMU = lots of familiar 'Linux' things not available or break.
ACK. And tell that a customer that everything is more effort and more
risk and not just "simply cross-compile it as it runs on my desktop
too".
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
^ permalink raw reply
* Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected
From: Greg Ungerer @ 2008-08-28 0:06 UTC (permalink / raw)
To: Jamie Lokier
Cc: Bernd Petrovitsch, Parag Warudkar, Linus Torvalds, Adrian Bunk,
Rusty Russell, Alan D. Brunelle, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Andrew Morton,
Arjan van de Ven, Ingo Molnar, linux-embedded
In-Reply-To: <20080827175152.GA27491@shareable.org>
Jamie Lokier wrote:
> Bernd Petrovitsch wrote:
>>> 32MB no-MMU ARM boards which people run new things and attach new
>>> devices to rather often - without making new hardware. Volume's too
>>> low per individual application to get new hardware designed and made.
>> Yes, you may have several products on the same hardware with somewhat
>> differing requirements (or not). But that is much less than a general
>> purpose system IMHO.
>
> It is, but the idea that small embedded systems go through a 'all
> components are known, drivers are known, test and if it passes it's
> shippable' does not always apply.
>
>>> I'm seriously thinking of forwarding porting the 4 year old firmware
>>> from 2.4.26 to 2.6.current, just to get new drivers and capabilities.
>> That sounds reasonable (and I never meant maintaining the old system
>> infinitely.
>
> Sounds reasonable, but it's vetoed for anticipated time and cost,
> compared with backporting on demand. Fair enough, since 2.6.current
> doesn't support ARM no-MMU last I heard ('soon'?).
>
> On the other hand, the 2.6 anti-fragmentation patches, including
> latest SLUB stuff, ironically meant to help big machines, sound really
> appealing for my current problem and totally unrealistic to
> backport...
>
>> ACK. We avoid MMU-less hardware too - especially since there is enough
>> hardware with a MMU around.
>
> I can't emphasise enough how much difference MMU makes to Linux userspace.
>
> It's practically: MMU = standard Linux (with less RAM), have everything.
> No-MMU = lots of familiar 'Linux' things not available or break.
And lots of things work in the usual way...
Of course the flip side is that for people who have platforms
without MMU they can run something more than the mostly "toy"
like operating systems typically available. There are plenty of
problem domains that the non-MMU limitations are not a problem for.
(Yours doesn't sound like one of them :-)
Regards
Greg
------------------------------------------------------------------------
Greg Ungerer -- Chief Software Dude EMAIL: gerg@snapgear.com
Secure Computing Corporation PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com
^ permalink raw reply
* Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected
From: Greg Ungerer @ 2008-08-28 0:11 UTC (permalink / raw)
To: Jamie Lokier
Cc: Bernd Petrovitsch, Parag Warudkar, Linus Torvalds, Adrian Bunk,
Rusty Russell, Alan D. Brunelle, Rafael J. Wysocki,
Linux Kernel Mailing List, Kernel Testers List, Andrew Morton,
Arjan van de Ven, Ingo Molnar,
linux-embedded-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20080827154805.GA25387-yetKDKU6eevNLxjTenLetw@public.gmane.org>
Jamie Lokier wrote:
> Bernd Petrovitsch wrote:
>> If you "develop" an embedded system (which is partly system integration
>> of existing apps) to be installed in the field, you don't have that many
>> conceivable work loads compared to a desktop/server system. And you have
>> a fixed list of drivers and applications.
>
> Hah! Not in my line of embedded device.
>
> 32MB no-MMU ARM boards which people run new things and attach new
> devices to rather often - without making new hardware. Volume's too
> low per individual application to get new hardware designed and made.
>
> I'm seriously thinking of forwarding porting the 4 year old firmware
> from 2.4.26 to 2.6.current, just to get new drivers and capabilities.
> Backporting is tedious, so's feeling wretchedly far from the mainline
> world.
>
>> A usual approach is to run stress tests on several (or all)
>> subsystems/services/... in parallel and if the device survives it
>> functioning correctly, it is at least good enough.
>
> Per application.
>
> Some little devices run hundreds of different applications and
> customers expect to customise, script themselves, and attach different
> devices (over USB). The next customer in the chain expects the bits
> you supplied to work in a variety of unexpected situations, even when
> you advise that it probably won't do that.
>
> Much like desktop/server Linux, but on a small device where silly
> little things like 'create a process' are a stress for the dear little
> thing.
>
> (My biggest lesson: insist on an MMU next time!)
But given you have hardware you can't change would you choose
to not run Linux, even with the limitations of non-MMU?
Hell no :-)
Regards
Greg
------------------------------------------------------------------------
Greg Ungerer -- Chief Software Dude EMAIL: gerg-XXXsiaCtIV5Wk0Htik3J/w@public.gmane.org
Secure Computing Corporation PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com
^ permalink raw reply
* Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected
From: Paul Mundt @ 2008-08-28 0:32 UTC (permalink / raw)
To: Adrian Bunk
Cc: Linus Torvalds, Rusty Russell, Alan D. Brunelle,
Rafael J. Wysocki, Linux Kernel Mailing List, Kernel Testers List,
Andrew Morton, Arjan van de Ven, Ingo Molnar, linux-embedded
In-Reply-To: <20080827173544.GH11734@cs181140183.pp.htv.fi>
On Wed, Aug 27, 2008 at 08:35:44PM +0300, Adrian Bunk wrote:
> On Thu, Aug 28, 2008 at 01:00:52AM +0900, Paul Mundt wrote:
> > On Wed, Aug 27, 2008 at 02:58:30PM +0300, Adrian Bunk wrote:
> > In addition to that, debugging the runaway stack users on 4k tends to be
> > easier anyways since you end up blowing the stack a lot sooner. On sh
> > we've had pretty good luck with it, though most of our users are using
> > fairly deterministic workloads and continually profiling the footprint.
> > Anything that runs away or uses an insane amount of stack space needs to
> > be fixed well before that anyways, so catching it sooner is always
> > preferable. I imagine the same case is true for m68knommu (even sans IRQ
> > stacks).
>
> CONFIG_DEBUG_STACKOVERFLOW should give you the same information, and if
> wanted with an arbitrary limit.
>
In some cases, yes. In the CONFIG_DEBUG_STACKOVERFLOW case the check is
only performed from do_IRQ(), which is sporadic at best, especially on
tickless. While it catches some things, it's not a complete solution in
and of iteslf.
In addition to this, there are even fewer platforms that support it than
there are platforms that do 4k stacks. At first glance, it looks like
it's only m32r, powerpc, sh, x86, and xtensa. Others support the Kconfig
option, but don't seem to realize that it's not an option that the kernel
does anything with by itself, and so don't actually do anything (ie,
FRV).
> > Things might be more sensitive on x86, but it's certainly not something
> > that's a huge problem for the various embedded platforms to wire up,
> > whether they want to go the IRQ stack route or not.
>
> How many platforms use 4kB stacks on sh?
>
> Only 1 out of 34 defconfigs uses it.
>
The defconfigs tend to enable as much random stuff as people are
interested in for development and testing purposes. Most of these end up
being reference boards and are the basis for products, rather than
shipping products themselves. In the latter case, everything is gradually
tightened down, and 4k stack utilization in that case is the norm, rather
than the exception.
> > In any event, lack of support for something on embedded architectures in
> > the kernel is more often due to apathy/utter indifference on the part of
> > the architecture maintainer rather than being indicative of any intrinsic
> > difficulty in supporting the thing in question. Most new "features" on the
> > lesser maintained architectures tend to end up there either out of peer
> > pressure or copying-and-pasting accidents rather than any sort of design.
> > ;-)
>
> arm or powerpc aren't exactly lesser maintained architectures.
>
Indeed, which is why I find it bizarre that you would even bother
applying what was said to those platforms. Specifically I was referring
to the embedded platforms that don't do 4k stacks today. The fact they
don't support them today has much less to do with 4k being an
unattainable limit as it does with people simply not bothering to
implement it on their platform.
> IMHO there seems to currently be a mismatch between it's maintainance
> cost and the actual number of users. That's in my opinion the main
> problem with it, no matter in which direction it gets resolved.
>
Perhaps that's true on x86, but in general I take issue with that. On sh
we've had to do very little maintenance for it and most shipping products
are using it today (at least on MMU-Linux, we don't bother with it on
nommu). Most of the problems we ran in to with 4k stacks tended to be
stuff that we wanted to fix for 8k anyways. I suspect that this case is
true for the other embedded platforms also.
Note that on sh we also conditionalize IRQ stacks separately, so while
they are often used together, it's possible to use 4k stacks without
resorting to IRQ stacks (as m68knommu also seems to do).
^ permalink raw reply
* Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected
From: David Miller @ 2008-08-28 0:46 UTC (permalink / raw)
To: lethal
Cc: bunk, torvalds, rusty, Alan.Brunelle, rjw, linux-kernel,
kernel-testers, akpm, arjan, mingo, linux-embedded
In-Reply-To: <20080828003211.GA18893@linux-sh.org>
From: Paul Mundt <lethal@linux-sh.org>
Date: Thu, 28 Aug 2008 09:32:13 +0900
> On Wed, Aug 27, 2008 at 08:35:44PM +0300, Adrian Bunk wrote:
> > CONFIG_DEBUG_STACKOVERFLOW should give you the same information, and if
> > wanted with an arbitrary limit.
>
> In some cases, yes. In the CONFIG_DEBUG_STACKOVERFLOW case the check is
> only performed from do_IRQ(), which is sporadic at best, especially on
> tickless. While it catches some things, it's not a complete solution in
> and of iteslf.
BTW, on sparc64 we have a stack overflow checker that runs via
the profiling _mcount hook. So every function call we check
if the stack is getting overused.
If so, we jump onto a special static debugging stack and print
the stack overflow message.
And yes it works with IRQ stacks which is all that sparc64 uses
nowadays.
Perhaps this is useful enough to make generic.
^ permalink raw reply
* Re: [Bug #11342] Linux 2.6.27-rc3: kernel BUG at mm/vmalloc.c - bisected
From: Paul Mundt @ 2008-08-28 1:02 UTC (permalink / raw)
To: David Miller
Cc: bunk-DgEjT+Ai2ygdnm+yROfE0A,
torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
rusty-8n+1lVoiYb80n/F98K4Iww, Alan.Brunelle-VXdhtT5mjnY,
rjw-KKrjLPT3xs0, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kernel-testers-u79uwXL29TY76Z2rM5mHXA,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
arjan-VuQAYsv1563Yd54FQh9/CA, mingo-X9Un+BFzKDI,
linux-embedded-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20080827.174605.85608276.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On Wed, Aug 27, 2008 at 05:46:05PM -0700, David Miller wrote:
> From: Paul Mundt <lethal-M7jkjyW5wf5g9hUCZPvPmw@public.gmane.org>
> Date: Thu, 28 Aug 2008 09:32:13 +0900
>
> > On Wed, Aug 27, 2008 at 08:35:44PM +0300, Adrian Bunk wrote:
> > > CONFIG_DEBUG_STACKOVERFLOW should give you the same information, and if
> > > wanted with an arbitrary limit.
> >
> > In some cases, yes. In the CONFIG_DEBUG_STACKOVERFLOW case the check is
> > only performed from do_IRQ(), which is sporadic at best, especially on
> > tickless. While it catches some things, it's not a complete solution in
> > and of iteslf.
>
> BTW, on sparc64 we have a stack overflow checker that runs via
> the profiling _mcount hook. So every function call we check
> if the stack is getting overused.
>
> If so, we jump onto a special static debugging stack and print
> the stack overflow message.
>
> And yes it works with IRQ stacks which is all that sparc64 uses
> nowadays.
>
> Perhaps this is useful enough to make generic.
Thanks for the pointer, I'll take a look at it!
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox