Messages in this thread | | | From | (Linus Torvalds) | Subject | Re: stack overruns [was: Re: "Please HELP"-crash] | Date | 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/
| |