Re: Announce: DinX windowing system 0.2.0

Khimenko Victor (khim@sch57.msk.ru)
Sat, 25 Dec 1999 19:15:49 +0300 (MSK)


In <Pine.LNX.4.10.9912260051110.695-100000@bart.linux.bogus> Ben Williamson (benw@pobox.com) wrote:
BW> On Sat, 25 Dec 1999, Khimenko Victor wrote:

>> > Something else I should mention: The clipping code performs no memory
>> > allocations, so drawing keeps off the heap. When an obscuring window
>> > splits a rectangular blit into two rectangles, the routine recurses for
>> > each, so the complexity of the visible area goes on the stack. Now, how
>> > much stack space does the kernel have? :)
>>
>> Kernel stack is TINY. On iX86 it's only 7KiB or so. And when you'll overflow
>> if you'll corrupt you system badly, BTW.

BW> Doh! Ok, I need to learn more. I take it this means recursive in kernel
BW> is totally a bad idea then?

Exactly. Recursion more then few levels deep is not an option here.

BW> I can either try to deal with this dynamically by checking how much stack
BW> is left, or just completely changing strategies to put all the dynamic
BW> stuff in a growable heap chunk. What do you recommend?

I'm not sure what is better in your case but if resursion can be more then
few levels deep in normal (not pathological) situations then better to avoid
resursion altogether.

BW> Doh doh doh...

BW> BTW, what are symptoms of stack overflow? Any pointers to required
BW> reading here? Thanks.

It's somewhere in the sources :-) Basic idea is simple: kernel stack use 2 pages
(4KiB each) at fixed position in memory (in virtual memory that is :-) but on
the bottom of stack there are current task struct (960 bytes in 2.2 if I recall
correct). So in stack overflow case you'll ruin that structure and get random
kernel oops. On other hand structure of kernel stack is simple so checking for
stack overflow can be done easy.

P.S. All this stuff is architecture-dependant but kernel stack is TINY on all
architectures. Why ? Since you need kernel stack for EVERY task in system and
it's NON-SWAPABLE area !

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/