>From what I saw, it happened when the next page is not mapped to
physical memory.
I don't think that stack corruption can cause this.
>From what I could understand about of the code there is not check if
the memory beyond stack is physically mapped or not.
To handle the problem I thought that c
On 24 September 2013 07:23, Anurag Aggarwal wrote:
> While executing unwind backtrace instructions in ARM, in the function
> unwind_exec_insn()
> there are chances that SP overflows from stack.
>
>
> For example while executing instruction with opcode 0xAE, vsp can go
> beyond stack to area that h
Hi Jean,
I don't think that it is related to the warning that you have suggested
On Tue, Sep 24, 2013 at 11:58 AM, Jean Pihet wrote:
> Hi,
>
> Adding Russell and l.a.k ML.
>
> Another question: is this linked to the following build warning?
> CC arch/arm/kernel/return_address.o
> arch/arm
Hi,
Adding Russell and l.a.k ML.
Another question: is this linked to the following build warning?
CC arch/arm/kernel/return_address.o
arch/arm/kernel/return_address.c:63:2: warning: #warning "TODO:
return_address should use unwind tables"
Regards,
Jean
On 24 September 2013 07:23, Anurag
Hi All,
While executing unwind backtrace instructions in ARM, in the function
unwind_exec_insn()
there are chances that SP overflows from stack.
For example while executing instruction with opcode 0xAE, vsp can go
beyond stack to area that has not been allocated till now.
unsigned long *vsp = (
5 matches
Mail list logo
