unsubscribe linux-kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
unsubscribe linux-kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
unsubscribe linux-kernel
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
unsubscribe linux-kernel
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Any more update on the patch.?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Any more update on the patch.?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
, where a check for
feasibility is made before reading each word from the stack.
Signed-off-by: Anurag Aggarwal
Reviewed-by: Dave Martin
---
arch/arm/kernel/unwind.c | 137 +-
1 file changed, 100 insertions(+), 37 deletions(-)
diff --git a/arch/arm
, where a check for
feasibility is made before reading each word from the stack.
Signed-off-by: Anurag Aggarwal a.anu...@samsung.com
Reviewed-by: Dave Martin dave.mar...@arm.com
---
arch/arm/kernel/unwind.c | 137 +-
1 file changed, 100 insertions
uiet
a few times in dmesg log.
So, the error condition is being handled.
If you have some test cases for verifying the unwinder, please share
the same. They might help
in thorough testing of unwinder.
Regards
On Wed, Dec 11, 2013 at 3:10 PM, Anurag Aggarwal wrote:
>>You could try adding som
condition is being handled.
If you have some test cases for verifying the unwinder, please share
the same. They might help
in thorough testing of unwinder.
Regards
On Wed, Dec 11, 2013 at 3:10 PM, Anurag Aggarwal a.anu...@samsung.com wrote:
You could try adding some debug printks to see how
>You could try adding some debug printks to see how the backtrace fails.
>You could also try adding a few hand-crafted assembler functions
>with appropriate code and unwind directives to trigger different kinds
>of backtrace failure. You might have to add a way to artificially limit
>sp_high to
You could try adding some debug printks to see how the backtrace fails.
You could also try adding a few hand-crafted assembler functions
with appropriate code and unwind directives to trigger different kinds
of backtrace failure. You might have to add a way to artificially limit
sp_high to check
s that such corner cases are being handled by the above code
Regards
Anurag
On Tue, Dec 10, 2013 at 9:24 AM, Anurag Aggarwal wrote:
>>Reviewed-by: Dave Martin
>>
>>I can confirm that the kernel "doesn't crash" with this applied, and
>>that backtracing at least p
are being handled by the above code
Regards
Anurag
On Tue, Dec 10, 2013 at 9:24 AM, Anurag Aggarwal a.anu...@samsung.com wrote:
Reviewed-by: Dave Martin dave.mar...@arm.com
I can confirm that the kernel doesn't crash with this applied, and
that backtracing at least partially works
>Reviewed-by: Dave Martin
>
>I can confirm that the kernel "doesn't crash" with this applied, and
>that backtracing at least partially works. But this is not really
>sufficient to demontrate that the now code works better than the old
>code in corner cases (which is the point of the patch).
>
, where a check for
feasibility is made before reading each word from the stack.
Signed-off-by: Anurag Aggarwal
---
arch/arm/kernel/unwind.c | 137 +
1 files changed, 100 insertions(+), 37 deletions(-)
diff --git a/arch/arm/kernel/unwind.c b/arch/arm
, where a check for
feasibility is made before reading each word from the stack.
Signed-off-by: Anurag Aggarwal a.anu...@samsung.com
---
arch/arm/kernel/unwind.c | 137 +
1 files changed, 100 insertions(+), 37 deletions(-)
diff --git a/arch/arm/kernel
Reviewed-by: Dave Martin dave.mar...@arm.com
I can confirm that the kernel doesn't crash with this applied, and
that backtracing at least partially works. But this is not really
sufficient to demontrate that the now code works better than the old
code in corner cases (which is the point of the
41 PM, Dave Martin wrote:
> On Fri, Dec 06, 2013 at 06:09:53AM +, Anurag Aggarwal wrote:
>> While unwinding backtrace, stack overflow is possible. This stack
>> overflow can sometimes lead to data abort in system if the area after
>> stack is not mapped to physical memory
, Anurag Aggarwal wrote:
While unwinding backtrace, stack overflow is possible. This stack
overflow can sometimes lead to data abort in system if the area after
stack is not mapped to physical memory.
To prevent this problem from happening, execute the instructions that
can cause a data abort
, where a check for
feasibility is made before reading each word from the stack.
Signed-off-by: Anurag Aggarwal
---
arch/arm/kernel/unwind.c | 138 ++-
1 file changed, 100 insertions(+), 38 deletions(-)
diff --git a/arch/arm/kernel/unwind.c b/arch/arm
;>That should probably be checked if it's not done already.
I think this should be handled in separate patch
I would also like to hear more your ideas for the file
Regards
Anurag
On Thu, Dec 5, 2013 at 7:29 PM, Dave Martin wrote:
> On Thu, Dec 05, 2013 at 11:26:25AM +, Anurag Aggarwal wrot
, where a check for
feasibility is made before reading each word from the stack.
Signed-off-by: Anurag Aggarwal
---
arch/arm/kernel/unwind.c | 127 -
1 files changed, 90 insertions(+), 37 deletions(-)
diff --git a/arch/arm/kernel/unwind.c b/arch/arm
, where a check for
feasibility is made before reading each word from the stack.
Signed-off-by: Anurag Aggarwal a.anu...@samsung.com
---
arch/arm/kernel/unwind.c | 127 -
1 files changed, 90 insertions(+), 37 deletions(-)
diff --git a/arch/arm/kernel
.
I think this should be handled in separate patch
I would also like to hear more your ideas for the file
Regards
Anurag
On Thu, Dec 5, 2013 at 7:29 PM, Dave Martin dave.mar...@arm.com wrote:
On Thu, Dec 05, 2013 at 11:26:25AM +, Anurag Aggarwal wrote:
While unwinding backtrace, stack overflow
, where a check for
feasibility is made before reading each word from the stack.
Signed-off-by: Anurag Aggarwal a.anu...@samsung.com
---
arch/arm/kernel/unwind.c | 138 ++-
1 file changed, 100 insertions(+), 38 deletions(-)
diff --git a/arch/arm/kernel
Signed-off-by: Anurag Aggarwal
While unwinding backtrace, stack overflow is possible. This stack
overflow can sometimes lead to data abort in system if the area after
stack is not mapped to physical memory.
To prevent this problem from happening, execute the instructions that
can cause a data
Signed-off-by: Anurag Aggarwal a.anu...@samsung.com
While unwinding backtrace, stack overflow is possible. This stack
overflow can sometimes lead to data abort in system if the area after
stack is not mapped to physical memory.
To prevent this problem from happening, execute the instructions
>> Looks like you still need to move your S-o-B line. It needs to be at
>> the end of the commit message.
>>
>> On Fri, Nov 29, 2013 at 09:34:31AM +, Anurag Aggarwal wrote:
>>> While unwinding backtrace, stack overflow is possible. This stack overflow
>>
> Looks like you still need to move your S-o-B line. It needs to be at
> the end of the commit message.
>
> On Fri, Nov 29, 2013 at 09:34:31AM +0000, Anurag Aggarwal wrote:
>> While unwinding backtrace, stack overflow is possible. This stack overflow
>> can sometim
Looks like you still need to move your S-o-B line. It needs to be at
the end of the commit message.
On Fri, Nov 29, 2013 at 09:34:31AM +, Anurag Aggarwal wrote:
While unwinding backtrace, stack overflow is possible. This stack overflow
can sometimes
lead to data abort in system
Looks like you still need to move your S-o-B line. It needs to be at
the end of the commit message.
On Fri, Nov 29, 2013 at 09:34:31AM +, Anurag Aggarwal wrote:
While unwinding backtrace, stack overflow is possible. This stack overflow
can sometimes
lead to data abort in system
While unwinding backtrace, stack overflow is possible. This stack overflow can
sometimes
lead to data abort in system if the area after stack is not mapped to physical
memory.
To prevent this problem from happening execute the instructions that can cause
data
abort in there seperate functions
While unwinding backtrace, stack overflow is possible. This stack overflow can
sometimes
lead to data abort in system if the area after stack is not mapped to physical
memory.
To prevent this problem from happening execute the instructions that can cause
data
abort in there seperate functions
documentation I could find and t
he current code written.
So I believe that this condition will provide good optimization and will not
create
additional ways for the code to go wrong
Regards
Anurag Aggarwal
--- Original Message ---
Sender : Dave Martin
Date : Nov 29, 2013 01:54 (GMT+05:3
While executing some unwind instructions stack overflow can cause a data abort
when area beyond stack is not mapped to physical memory.
To prevent the data abort check whether it is possible to execute
these instructions before unwinding the stack
---
arch/arm/kernel/unwind.c | 59
While executing some unwind instructions stack overflow can cause a data abort
when area beyond stack is not mapped to physical memory.
To prevent the data abort check whether it is possible to execute
these instructions before unwinding the stack
---
arch/arm/kernel/unwind.c | 59
and t
he current code written.
So I believe that this condition will provide good optimization and will not
create
additional ways for the code to go wrong
Regards
Anurag Aggarwal
--- Original Message ---
Sender : Dave Martindave.mar...@arm.com
Date : Nov 29, 2013 01:54 (GMT+05:30)
Title
or not.
The above method will add some extra code but will avoid additional checks that
are not required every where.
and solve our purpose also as we need to avoid data abort due to stack overflow
not stack overflow completely.
Regards
Anurag Aggarwal
--- Original Message ---
Sender : Dave
or not.
The above method will add some extra code but will avoid additional checks that
are not required every where.
and solve our purpose also as we need to avoid data abort due to stack overflow
not stack overflow completely.
Regards
Anurag Aggarwal
--- Original Message ---
Sender : Dave
Regards
Anurag
On Fri, Nov 8, 2013 at 6:51 PM, Dave Martin wrote:
> On Wed, Nov 06, 2013 at 03:20:48PM +0530, Anurag Aggarwal wrote:
>> Altough stack overflow is expected in unwind_exec_insn, but in cases when
>> area beyond stack is not mapped to physical memory this can c
Regards
Anurag
On Fri, Nov 8, 2013 at 6:51 PM, Dave Martin dave.mar...@arm.com wrote:
On Wed, Nov 06, 2013 at 03:20:48PM +0530, Anurag Aggarwal wrote:
Altough stack overflow is expected in unwind_exec_insn, but in cases when
area beyond stack is not mapped to physical memory this can cause data
Altough stack overflow is expected in unwind_exec_insn, but in cases when area
beyond stack is not mapped to physical memory this can cause data abort.
To avoid above condition handle stack overflow in unwind_exec_insn by checking
vsp pointer from top of stack
Signed-off-by: Anurag Aggarwal
Altough stack overflow is expected in unwind_exec_insn, but in cases when area
beyond stack is not mapped to physical memory this can cause data abort.
To avoid above condition handle stack overflow in unwind_exec_insn by checking
vsp pointer from top of stack
Signed-off-by: Anurag Aggarwal
hought that checks can also be added in
unwind_exec_insn() function for stack overflow.
On Wed, Oct 2, 2013 at 11:41 PM, Catalin Marinas
wrote:
> On 24 September 2013 07:23, Anurag Aggarwal
> wrote:
>> While executing unwind backtrace instructions in ARM, in the function
&
that checks can also be added in
unwind_exec_insn() function for stack overflow.
On Wed, Oct 2, 2013 at 11:41 PM, Catalin Marinas
catalin.mari...@arm.com wrote:
On 24 September 2013 07:23, Anurag Aggarwal anurag19aggar...@gmail.com
wrote:
While executing unwind backtrace instructions in ARM
n_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 Aggarwal
> wrote:
>> Hi All,
>>
>> While executing unw
/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 Aggarwal anurag19aggar...@gmail.com
wrote:
Hi All,
While executing unwind backtrace instructions in ARM, in the function
place to ask
the question.
--
Anurag Aggarwal
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
.
--
Anurag Aggarwal
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
50 matches
Mail list logo
