Doh!

[Owen]

I've just spent forever investigating a stack corruption issue. For some reason my stack was getting corrupted while allocating all the PDEs for kernel space. I checked all my functions were correct, nowhere was trashing memory that it wasn't supposed to, and was completely stumped.

I sat on it for a few hours, then re-ran the code under Bochs. Then I noticed something interesting...
...The address of the PDE I was modifying was suspicioulsy similar to ESP...
...And ESP pointed somewhere inside my boot page directory!

My initial thought was that my stack was too small, but I found it difficult to believe that I was consuming 64kB of stack. Then, I noticed something.

My stack is defined in kmain.c:

Code: Select all

__attribute__((aligned(32))) u32 BootStack[0x4000];
u32* BootStackTop = BootStack + 0x4000;

My entry code does this:

Code: Select all

movl $BootStackTop, %esp

Spotted it yet?

BootStackTop is the address of a pointer which points to the stack. I should have been doing

Code: Select all

movl BootStackTop, %esp

Doh! That bug has been in my kernel the entire time without me noticing it!

BootStackTop is, coincidentally, located just above the page tables.

And I now know that I use about 256 bytes of stack :p

[AJ]

As you may have seen in the auto-delete forum, I've had one of those "slap yourself on the forehead" debug moments recently!

May I suggest that in learning from this you now put more space between the stack and tables - presumably when paging is enabled you will have a guard page set up anyway. Although it is unlikely that you would consume all that stack at present, there's always that recursive function that could go AWOL

Cheers,
Adam

[Owen]

Now that you've made me think about it, the kernel stack has been page aligned and the first 4kb of it unmapped

Once I get guard page support in, I'll mark it as such so the kernel can pop up an appropriate panic