[okl4-developer] pagefault

[Frank Kaiser]

> -----Original Message-----
> Hi Frank
> 
> > My point is the stack manipulation. The value of the constant
STACK_TOP
> > is defined in 'arch/arm/pistachio/include/config.h' and has the
value
> > 0x3F8 (STACK_SIZE-8). Since the stack pointer is manipulated in 4
bytes
> > steps, the result of the OR operation will leave the low ten bits of
SP
> > either 0x3F8 or 0x3FC which is near the top of the current stack
> > provided that all stacks are adjusted to a 1k boundary. The dubious
> > thing is that one does not always get the same stack value once the
> > macro has been executed: possibly that does not matter, because both
> > pattern result in a stack pointer value within the defined memory
range.
> ...
> 
> This is only the kernel stack.  We carefully manage the stack usage
> so that it won't overflow.
> 
> >
> > Regards
> > Frank
> 
> 	-gl
Hi, Geoffrey

Thanks for your response to the subject. I am still in the process of
advancing my understanding of OKL4.
Can you please elaborate a bit more what you mention above about stack
management? I am still concerned about this stack manipulation, that
this OR operation to calculate the top of the current stack does not
always return the same value.
Lets assume that the memory reserved for a stack is 4 kB (the minimum
ARM page size supported by the kernel), and the virtual start address is
0x80017000. The stack pointer SP of the thread would then be set to
0x80018FF8. The thread using this stack frame executes
ACTIVATE_CONTINUATION(). Depending on the current value of SP, the
operation 'SP |= STACK_STOP[0x3F8]' would give different results:
- SP = 0x80017CB0, after ACTIVATE_CONTINUATION(): SP = 0x80017FF8
- SP = 0x80017CB4, after ACTIVATE_CONTINUATION(): SP = 0x80017FFC
- SP = 0x80017AB0, after ACTIVATE_CONTINUATION(): SP = 0x80017DF8
- SP = 0x80017AB4, after ACTIVATE_CONTINUATION(): SP = 0x80017DFC
The first 2 examples show that the calculated stack top varies by an
offset of 4, which may not be critical, since sp stays below the upper
page border and will grow downward. But in the second 2 examples the
calculated stack top stays more than 1k (0x400) below the upper page
border. And the effect is cumulative: if the stack grows more than 1k
down from the new calculated stack, the offset will become 2k (0x800).
Over time the stack will wander down the page and possibly bypass the
lower border of the allocated memory resulting in a page fault.
I would very much appreciate if you could shed more light on the issue
and provide explanations which render my concerns invalid.

Regards
Frank