Re: stack overruns [was: Re: "Please HELP"-crash]

Linus Torvalds (torvalds@transmeta.com)
25 Apr 1999 17:34:40 GMT


In article <m10bSGH-0007TvC@the-village.bc.nu>,
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> 1) at system startup one huge block (16 kB per task slot, (8 kB stack +
>> 8 kB guard pages)) is vm_alloc'ed. The area must be 8 kB aligned.
>
>You can't vmalloc the stack without changing drivers that assume the stack
>is DMAable. Thats a 2.3.x thing but yes.

I think we want to avoid it even in 2.3.x - not only are there
potentially DMA-able areas in stack space (I know the driver I'm working
on - USB - has that behaviour), but I'd rather avoid having the TLB
impact of a mapped stack. On many architectures (including the x86 due
to the 4M pages), it is cheaper to have a 1:1 mapping than to have
normal page mappings.

> vmalloc I seem to remember already
>does guard pages

Yup.

>> 2) if a task is created, then 2 single pages get allocated,
>> and inserted into the vm_alloc'ed area.
>> 3) the task_struct is moved to the end of the stack.
>> (Windows 95 does it this way around)
>
>The task struct is where it is in order to make dereferencing current
>fast.

It's not much worse to move it to the end: you do it with something like
this:

get_current()
{
movl $0x1ffc,%edx
orl %esp,%edx
return %edx-(sizeof(struct task_struct)-4);
}

and then the compiler most of the time can use a negative memory offset
to essentially create the same code as we have now. The one real
downside is that instead of having a small positive offset you have a
larger negative one, which tends to take up more space. We could work
around that by putting the commonly used stuff at the end of the struct
task_struct, but I'm not sure it is worth it.

I considered doing it this way originally, I think I went with the
low-mem struct task_struct mainly because it was more obvious, and
because it can be cheaper. A high-mem struct task_struct has its own
advantages, though, so it's by no means a clear choice either way.

Linus

-
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/