<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/arch/arm/kernel/stacktrace.c, branch v4.9.321</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>ARM: 9191/1: arm/stacktrace, kasan: Silence KASAN warnings in unwind_frame()</title>
<updated>2022-05-25T06:39:48+00:00</updated>
<author>
<name>linyujun</name>
<email>linyujun809@huawei.com</email>
</author>
<published>2022-04-01T09:52:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=22948c981625cba2a90f046ecef74c2ff65b8a99'/>
<id>22948c981625cba2a90f046ecef74c2ff65b8a99</id>
<content type='text'>
[ Upstream commit 9be4c88bb7924f68f88cfd47d925c2d046f51a73 ]

The following KASAN warning is detected by QEMU.

==================================================================
BUG: KASAN: stack-out-of-bounds in unwind_frame+0x508/0x870
Read of size 4 at addr c36bba90 by task cat/163

CPU: 1 PID: 163 Comm: cat Not tainted 5.10.0-rc1 #40
Hardware name: ARM-Versatile Express
[&lt;c0113fac&gt;] (unwind_backtrace) from [&lt;c010e71c&gt;] (show_stack+0x10/0x14)
[&lt;c010e71c&gt;] (show_stack) from [&lt;c0b805b4&gt;] (dump_stack+0x98/0xb0)
[&lt;c0b805b4&gt;] (dump_stack) from [&lt;c0b7d658&gt;] (print_address_description.constprop.0+0x58/0x4bc)
[&lt;c0b7d658&gt;] (print_address_description.constprop.0) from [&lt;c031435c&gt;] (kasan_report+0x154/0x170)
[&lt;c031435c&gt;] (kasan_report) from [&lt;c0113c44&gt;] (unwind_frame+0x508/0x870)
[&lt;c0113c44&gt;] (unwind_frame) from [&lt;c010e298&gt;] (__save_stack_trace+0x110/0x134)
[&lt;c010e298&gt;] (__save_stack_trace) from [&lt;c01ce0d8&gt;] (stack_trace_save+0x8c/0xb4)
[&lt;c01ce0d8&gt;] (stack_trace_save) from [&lt;c0313520&gt;] (kasan_set_track+0x38/0x60)
[&lt;c0313520&gt;] (kasan_set_track) from [&lt;c0314cb8&gt;] (kasan_set_free_info+0x20/0x2c)
[&lt;c0314cb8&gt;] (kasan_set_free_info) from [&lt;c0313474&gt;] (__kasan_slab_free+0xec/0x120)
[&lt;c0313474&gt;] (__kasan_slab_free) from [&lt;c0311e20&gt;] (kmem_cache_free+0x7c/0x334)
[&lt;c0311e20&gt;] (kmem_cache_free) from [&lt;c01c35dc&gt;] (rcu_core+0x390/0xccc)
[&lt;c01c35dc&gt;] (rcu_core) from [&lt;c01013a8&gt;] (__do_softirq+0x180/0x518)
[&lt;c01013a8&gt;] (__do_softirq) from [&lt;c0135214&gt;] (irq_exit+0x9c/0xe0)
[&lt;c0135214&gt;] (irq_exit) from [&lt;c01a40e4&gt;] (__handle_domain_irq+0xb0/0x110)
[&lt;c01a40e4&gt;] (__handle_domain_irq) from [&lt;c0691248&gt;] (gic_handle_irq+0xa0/0xb8)
[&lt;c0691248&gt;] (gic_handle_irq) from [&lt;c0100b0c&gt;] (__irq_svc+0x6c/0x94)
Exception stack(0xc36bb928 to 0xc36bb970)
b920:                   c36bb9c0 00000000 c0126919 c0101228 c36bb9c0 b76d7730
b940: c36b8000 c36bb9a0 c3335b00 c01ce0d8 00000003 c36bba3c c36bb940 c36bb978
b960: c010e298 c011373c 60000013 ffffffff
[&lt;c0100b0c&gt;] (__irq_svc) from [&lt;c011373c&gt;] (unwind_frame+0x0/0x870)
[&lt;c011373c&gt;] (unwind_frame) from [&lt;00000000&gt;] (0x0)

The buggy address belongs to the page:
page:(ptrval) refcount:0 mapcount:0 mapping:00000000 index:0x0 pfn:0x636bb
flags: 0x0()
raw: 00000000 00000000 ef867764 00000000 00000000 00000000 ffffffff 00000000
page dumped because: kasan: bad access detected

addr c36bba90 is located in stack of task cat/163 at offset 48 in frame:
 stack_trace_save+0x0/0xb4

this frame has 1 object:
 [32, 48) 'trace'

Memory state around the buggy address:
 c36bb980: f1 f1 f1 f1 00 04 f2 f2 00 00 f3 f3 00 00 00 00
 c36bba00: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
&gt;c36bba80: 00 00 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
                 ^
 c36bbb00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 c36bbb80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
==================================================================

There is a same issue on x86 and has been resolved by the commit f7d27c35ddff
("x86/mm, kasan: Silence KASAN warnings in get_wchan()").
The solution could be applied to arm architecture too.

Signed-off-by: Lin Yujun &lt;linyujun809@huawei.com&gt;
Reported-by: He Ying &lt;heying24@huawei.com&gt;
Signed-off-by: Russell King (Oracle) &lt;rmk+kernel@armlinux.org.uk&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 9be4c88bb7924f68f88cfd47d925c2d046f51a73 ]

The following KASAN warning is detected by QEMU.

==================================================================
BUG: KASAN: stack-out-of-bounds in unwind_frame+0x508/0x870
Read of size 4 at addr c36bba90 by task cat/163

CPU: 1 PID: 163 Comm: cat Not tainted 5.10.0-rc1 #40
Hardware name: ARM-Versatile Express
[&lt;c0113fac&gt;] (unwind_backtrace) from [&lt;c010e71c&gt;] (show_stack+0x10/0x14)
[&lt;c010e71c&gt;] (show_stack) from [&lt;c0b805b4&gt;] (dump_stack+0x98/0xb0)
[&lt;c0b805b4&gt;] (dump_stack) from [&lt;c0b7d658&gt;] (print_address_description.constprop.0+0x58/0x4bc)
[&lt;c0b7d658&gt;] (print_address_description.constprop.0) from [&lt;c031435c&gt;] (kasan_report+0x154/0x170)
[&lt;c031435c&gt;] (kasan_report) from [&lt;c0113c44&gt;] (unwind_frame+0x508/0x870)
[&lt;c0113c44&gt;] (unwind_frame) from [&lt;c010e298&gt;] (__save_stack_trace+0x110/0x134)
[&lt;c010e298&gt;] (__save_stack_trace) from [&lt;c01ce0d8&gt;] (stack_trace_save+0x8c/0xb4)
[&lt;c01ce0d8&gt;] (stack_trace_save) from [&lt;c0313520&gt;] (kasan_set_track+0x38/0x60)
[&lt;c0313520&gt;] (kasan_set_track) from [&lt;c0314cb8&gt;] (kasan_set_free_info+0x20/0x2c)
[&lt;c0314cb8&gt;] (kasan_set_free_info) from [&lt;c0313474&gt;] (__kasan_slab_free+0xec/0x120)
[&lt;c0313474&gt;] (__kasan_slab_free) from [&lt;c0311e20&gt;] (kmem_cache_free+0x7c/0x334)
[&lt;c0311e20&gt;] (kmem_cache_free) from [&lt;c01c35dc&gt;] (rcu_core+0x390/0xccc)
[&lt;c01c35dc&gt;] (rcu_core) from [&lt;c01013a8&gt;] (__do_softirq+0x180/0x518)
[&lt;c01013a8&gt;] (__do_softirq) from [&lt;c0135214&gt;] (irq_exit+0x9c/0xe0)
[&lt;c0135214&gt;] (irq_exit) from [&lt;c01a40e4&gt;] (__handle_domain_irq+0xb0/0x110)
[&lt;c01a40e4&gt;] (__handle_domain_irq) from [&lt;c0691248&gt;] (gic_handle_irq+0xa0/0xb8)
[&lt;c0691248&gt;] (gic_handle_irq) from [&lt;c0100b0c&gt;] (__irq_svc+0x6c/0x94)
Exception stack(0xc36bb928 to 0xc36bb970)
b920:                   c36bb9c0 00000000 c0126919 c0101228 c36bb9c0 b76d7730
b940: c36b8000 c36bb9a0 c3335b00 c01ce0d8 00000003 c36bba3c c36bb940 c36bb978
b960: c010e298 c011373c 60000013 ffffffff
[&lt;c0100b0c&gt;] (__irq_svc) from [&lt;c011373c&gt;] (unwind_frame+0x0/0x870)
[&lt;c011373c&gt;] (unwind_frame) from [&lt;00000000&gt;] (0x0)

The buggy address belongs to the page:
page:(ptrval) refcount:0 mapcount:0 mapping:00000000 index:0x0 pfn:0x636bb
flags: 0x0()
raw: 00000000 00000000 ef867764 00000000 00000000 00000000 ffffffff 00000000
page dumped because: kasan: bad access detected

addr c36bba90 is located in stack of task cat/163 at offset 48 in frame:
 stack_trace_save+0x0/0xb4

this frame has 1 object:
 [32, 48) 'trace'

Memory state around the buggy address:
 c36bb980: f1 f1 f1 f1 00 04 f2 f2 00 00 f3 f3 00 00 00 00
 c36bba00: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
&gt;c36bba80: 00 00 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
                 ^
 c36bbb00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 c36bbb80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
==================================================================

There is a same issue on x86 and has been resolved by the commit f7d27c35ddff
("x86/mm, kasan: Silence KASAN warnings in get_wchan()").
The solution could be applied to arm architecture too.

Signed-off-by: Lin Yujun &lt;linyujun809@huawei.com&gt;
Reported-by: He Ying &lt;heying24@huawei.com&gt;
Signed-off-by: Russell King (Oracle) &lt;rmk+kernel@armlinux.org.uk&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: clang: Do not rely on lr register for stacktrace</title>
<updated>2021-11-26T10:48:31+00:00</updated>
<author>
<name>Masami Hiramatsu</name>
<email>mhiramat@kernel.org</email>
</author>
<published>2021-10-21T00:55:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=538c974c61e242ddf93202e29ba0c9be3c63e2ad'/>
<id>538c974c61e242ddf93202e29ba0c9be3c63e2ad</id>
<content type='text'>
[ Upstream commit b3ea5d56f212ad81328c82454829a736197ebccc ]

Currently the stacktrace on clang compiled arm kernel uses the 'lr'
register to find the first frame address from pt_regs. However, that
is wrong after calling another function, because the 'lr' register
is used by 'bl' instruction and never be recovered.

As same as gcc arm kernel, directly use the frame pointer (r11) of
the pt_regs to find the first frame address.

Note that this fixes kretprobe stacktrace issue only with
CONFIG_UNWINDER_FRAME_POINTER=y. For the CONFIG_UNWINDER_ARM,
we need another fix.

Signed-off-by: Masami Hiramatsu &lt;mhiramat@kernel.org&gt;
Reviewed-by: Nick Desaulniers &lt;ndesaulniers@google.com&gt;
Signed-off-by: Steven Rostedt (VMware) &lt;rostedt@goodmis.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit b3ea5d56f212ad81328c82454829a736197ebccc ]

Currently the stacktrace on clang compiled arm kernel uses the 'lr'
register to find the first frame address from pt_regs. However, that
is wrong after calling another function, because the 'lr' register
is used by 'bl' instruction and never be recovered.

As same as gcc arm kernel, directly use the frame pointer (r11) of
the pt_regs to find the first frame address.

Note that this fixes kretprobe stacktrace issue only with
CONFIG_UNWINDER_FRAME_POINTER=y. For the CONFIG_UNWINDER_ARM,
we need another fix.

Signed-off-by: Masami Hiramatsu &lt;mhiramat@kernel.org&gt;
Reviewed-by: Nick Desaulniers &lt;ndesaulniers@google.com&gt;
Signed-off-by: Steven Rostedt (VMware) &lt;rostedt@goodmis.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: 8992/1: Fix unwind_frame for clang-built kernels</title>
<updated>2020-08-21T09:02:06+00:00</updated>
<author>
<name>Nathan Huckleberry</name>
<email>nhuck@google.com</email>
</author>
<published>2020-07-10T19:23:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=121b25adedbfbec2e2d924249e95575821dd8da0'/>
<id>121b25adedbfbec2e2d924249e95575821dd8da0</id>
<content type='text'>
commit b4d5ec9b39f8b31d98f65bc5577b5d15d93795d7 upstream.

Since clang does not push pc and sp in function prologues, the current
implementation of unwind_frame does not work. By using the previous
frame's lr/fp instead of saved pc/sp we get valid unwinds on clang-built
kernels.

The bounds check on next frame pointer must be changed as well since
there are 8 less bytes between frames.

This fixes /proc/&lt;pid&gt;/stack.

Link: https://github.com/ClangBuiltLinux/linux/issues/912

Reported-by: Miles Chen &lt;miles.chen@mediatek.com&gt;
Tested-by: Miles Chen &lt;miles.chen@mediatek.com&gt;
Cc: stable@vger.kernel.org
Reviewed-by: Nick Desaulniers &lt;ndesaulniers@google.com&gt;
Signed-off-by: Nathan Huckleberry &lt;nhuck@google.com&gt;
Signed-off-by: Russell King &lt;rmk+kernel@armlinux.org.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit b4d5ec9b39f8b31d98f65bc5577b5d15d93795d7 upstream.

Since clang does not push pc and sp in function prologues, the current
implementation of unwind_frame does not work. By using the previous
frame's lr/fp instead of saved pc/sp we get valid unwinds on clang-built
kernels.

The bounds check on next frame pointer must be changed as well since
there are 8 less bytes between frames.

This fixes /proc/&lt;pid&gt;/stack.

Link: https://github.com/ClangBuiltLinux/linux/issues/912

Reported-by: Miles Chen &lt;miles.chen@mediatek.com&gt;
Tested-by: Miles Chen &lt;miles.chen@mediatek.com&gt;
Cc: stable@vger.kernel.org
Reviewed-by: Nick Desaulniers &lt;ndesaulniers@google.com&gt;
Signed-off-by: Nathan Huckleberry &lt;nhuck@google.com&gt;
Signed-off-by: Russell King &lt;rmk+kernel@armlinux.org.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: 8172/1: Use current_stack_pointer in save_stack_trace_tsk</title>
<updated>2014-11-13T23:58:03+00:00</updated>
<author>
<name>Behan Webster</name>
<email>behanw@converseincode.com</email>
</author>
<published>2014-09-26T23:31:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=74dbeee0fcded9525ddb42b53ee75dc62c8089d9'/>
<id>74dbeee0fcded9525ddb42b53ee75dc62c8089d9</id>
<content type='text'>
Use the global current_stack_pointer to get the value of the stack pointer.
This change supports being able to compile the kernel with both gcc and clang.

Signed-off-by: Behan Webster &lt;behanw@converseincode.com&gt;
Reviewed-by: Mark Charlebois &lt;charlebm@gmail.com&gt;
Reviewed-by: Jan-Simon Möller &lt;dl9pf@gmx.de&gt;
Acked-by: Will Deacon &lt;will.deacon@arm.com&gt;
Acked-by: Nicolas Pitre &lt;nico@linaro.org&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Use the global current_stack_pointer to get the value of the stack pointer.
This change supports being able to compile the kernel with both gcc and clang.

Signed-off-by: Behan Webster &lt;behanw@converseincode.com&gt;
Reviewed-by: Mark Charlebois &lt;charlebm@gmail.com&gt;
Reviewed-by: Jan-Simon Möller &lt;dl9pf@gmx.de&gt;
Acked-by: Will Deacon &lt;will.deacon@arm.com&gt;
Acked-by: Nicolas Pitre &lt;nico@linaro.org&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: 8049/1: ftrace/add save_stack_trace_regs() implementation</title>
<updated>2014-05-30T00:12:32+00:00</updated>
<author>
<name>Lin Yongting</name>
<email>linyongting@gmail.com</email>
</author>
<published>2014-05-04T15:27:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=9c986661638c69772f5479c4715061239ec61b29'/>
<id>9c986661638c69772f5479c4715061239ec61b29</id>
<content type='text'>
When configure kprobe events of ftrace with "stacktrace" option enabled
in arm, there is no stacktrace was recorded after the kprobe event was
triggered. The root cause is no save_stack_trace_regs() function implemented.

Implement the save_stack_trace_regs() function in arm, then ftrace will
call this architecture-related function to record the stacktrace into
ring buffer.

After this fix, stacktrace can be recorded, for example:

 # mount -t debugfs nodev /sys/kernel/debug
 # echo "p:netrx net_rx_action" &gt;&gt; /sys/kernel/debug/tracing/kprobe_events
 # echo 1 &gt; /sys/kernel/debug/tracing/events/kprobes/netrx/enable
 # echo 1 &gt; /sys/kernel/debug/tracing/options/stacktrace
 # echo 1 &gt; /sys/kernel/debug/tracing/tracing_on
 # ping 127.0.0.1 -c 1
 # echo 0 &gt; /sys/kernel/debug/tracing/tracing_on

 # cat /sys/kernel/debug/tracing/trace
 # tracer: nop
 #
 # entries-in-buffer/entries-written: 12/12   #P:1
 #
 #                              _-----=&gt; irqs-off
 #                             / _----=&gt; need-resched
 #                            | / _---=&gt; hardirq/softirq
 #                            || / _--=&gt; preempt-depth
 #                            ||| /     delay
 #           TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION
 #              | |       |   ||||       |         |
             &lt;------ missing some entries ----------------&gt;
             ping-1200  [000] dNs1   667.603250: netrx: (net_rx_action+0x0/0x1f8)
             ping-1200  [000] dNs1   667.604738: &lt;stack trace&gt;
  =&gt; net_rx_action
  =&gt; do_softirq
  =&gt; local_bh_enable
  =&gt; ip_finish_output
  =&gt; ip_output
  =&gt; ip_local_out
  =&gt; ip_send_skb
  =&gt; ip_push_pending_frames
  =&gt; raw_sendmsg
  =&gt; inet_sendmsg
  =&gt; sock_sendmsg
  =&gt; SyS_sendto
  =&gt; ret_fast_syscall

Signed-off-by: Lin Yongting &lt;linyongting@gmail.com&gt;
Acked-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When configure kprobe events of ftrace with "stacktrace" option enabled
in arm, there is no stacktrace was recorded after the kprobe event was
triggered. The root cause is no save_stack_trace_regs() function implemented.

Implement the save_stack_trace_regs() function in arm, then ftrace will
call this architecture-related function to record the stacktrace into
ring buffer.

After this fix, stacktrace can be recorded, for example:

 # mount -t debugfs nodev /sys/kernel/debug
 # echo "p:netrx net_rx_action" &gt;&gt; /sys/kernel/debug/tracing/kprobe_events
 # echo 1 &gt; /sys/kernel/debug/tracing/events/kprobes/netrx/enable
 # echo 1 &gt; /sys/kernel/debug/tracing/options/stacktrace
 # echo 1 &gt; /sys/kernel/debug/tracing/tracing_on
 # ping 127.0.0.1 -c 1
 # echo 0 &gt; /sys/kernel/debug/tracing/tracing_on

 # cat /sys/kernel/debug/tracing/trace
 # tracer: nop
 #
 # entries-in-buffer/entries-written: 12/12   #P:1
 #
 #                              _-----=&gt; irqs-off
 #                             / _----=&gt; need-resched
 #                            | / _---=&gt; hardirq/softirq
 #                            || / _--=&gt; preempt-depth
 #                            ||| /     delay
 #           TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION
 #              | |       |   ||||       |         |
             &lt;------ missing some entries ----------------&gt;
             ping-1200  [000] dNs1   667.603250: netrx: (net_rx_action+0x0/0x1f8)
             ping-1200  [000] dNs1   667.604738: &lt;stack trace&gt;
  =&gt; net_rx_action
  =&gt; do_softirq
  =&gt; local_bh_enable
  =&gt; ip_finish_output
  =&gt; ip_output
  =&gt; ip_local_out
  =&gt; ip_send_skb
  =&gt; ip_push_pending_frames
  =&gt; raw_sendmsg
  =&gt; inet_sendmsg
  =&gt; sock_sendmsg
  =&gt; SyS_sendto
  =&gt; ret_fast_syscall

Signed-off-by: Lin Yongting &lt;linyongting@gmail.com&gt;
Acked-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: stacktrace: include exception PC value in stacktrace output</title>
<updated>2014-05-22T15:33:24+00:00</updated>
<author>
<name>Russell King</name>
<email>rmk+kernel@arm.linux.org.uk</email>
</author>
<published>2014-05-03T15:17:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=07b403415884e961920f55e6db462dff15d9df5a'/>
<id>07b403415884e961920f55e6db462dff15d9df5a</id>
<content type='text'>
When we unwind through an exception stack, include the saved PC value
into the stack trace: this fills in an otherwise missed functions from
the trace (as indicated below):

 [&lt;c03f4424&gt;] fec_enet_interrupt+0xa0/0xe8
 [&lt;c0066c0c&gt;] handle_irq_event_percpu+0x68/0x228
 [&lt;c0066e18&gt;] handle_irq_event+0x4c/0x6c
 [&lt;c006a024&gt;] handle_fasteoi_irq+0xac/0x198
 [&lt;c00664b0&gt;] generic_handle_irq+0x4c/0x60
 [&lt;c000f014&gt;] handle_IRQ+0x40/0x98
 [&lt;c0008554&gt;] gic_handle_irq+0x30/0x64
 [&lt;c0012900&gt;] __irq_svc+0x40/0x50
 [&lt;c0029030&gt;] __do_softirq+0xe0/0x2fc		&lt;====
 [&lt;c0029500&gt;] irq_exit+0xb0/0x100
 [&lt;c000f018&gt;] handle_IRQ+0x44/0x98
 [&lt;c0008554&gt;] gic_handle_irq+0x30/0x64
 [&lt;c0012900&gt;] __irq_svc+0x40/0x50
 [&lt;c000f34c&gt;] arch_cpu_idle+0x30/0x38		&lt;====
 [&lt;c005e1e4&gt;] cpu_startup_entry+0xac/0x214
 [&lt;c066297c&gt;] rest_init+0x68/0x80
 [&lt;c08ccb10&gt;] start_kernel+0x2fc/0x358

Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When we unwind through an exception stack, include the saved PC value
into the stack trace: this fills in an otherwise missed functions from
the trace (as indicated below):

 [&lt;c03f4424&gt;] fec_enet_interrupt+0xa0/0xe8
 [&lt;c0066c0c&gt;] handle_irq_event_percpu+0x68/0x228
 [&lt;c0066e18&gt;] handle_irq_event+0x4c/0x6c
 [&lt;c006a024&gt;] handle_fasteoi_irq+0xac/0x198
 [&lt;c00664b0&gt;] generic_handle_irq+0x4c/0x60
 [&lt;c000f014&gt;] handle_IRQ+0x40/0x98
 [&lt;c0008554&gt;] gic_handle_irq+0x30/0x64
 [&lt;c0012900&gt;] __irq_svc+0x40/0x50
 [&lt;c0029030&gt;] __do_softirq+0xe0/0x2fc		&lt;====
 [&lt;c0029500&gt;] irq_exit+0xb0/0x100
 [&lt;c000f018&gt;] handle_IRQ+0x44/0x98
 [&lt;c0008554&gt;] gic_handle_irq+0x30/0x64
 [&lt;c0012900&gt;] __irq_svc+0x40/0x50
 [&lt;c000f34c&gt;] arch_cpu_idle+0x30/0x38		&lt;====
 [&lt;c005e1e4&gt;] cpu_startup_entry+0xac/0x214
 [&lt;c066297c&gt;] rest_init+0x68/0x80
 [&lt;c08ccb10&gt;] start_kernel+0x2fc/0x358

Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: stacktrace: avoid listing stacktrace functions in stacktrace</title>
<updated>2014-05-22T15:33:19+00:00</updated>
<author>
<name>Russell King</name>
<email>rmk+kernel@arm.linux.org.uk</email>
</author>
<published>2014-05-03T10:03:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=3683f44c42e991d313dc301504ee0fca1aeb8580'/>
<id>3683f44c42e991d313dc301504ee0fca1aeb8580</id>
<content type='text'>
While debugging the FEC ethernet driver using stacktrace, it was noticed
that the stacktraces always begin as follows:

 [&lt;c00117b4&gt;] save_stack_trace_tsk+0x0/0x98
 [&lt;c0011870&gt;] save_stack_trace+0x24/0x28
 ...

This is because the stack trace code includes the stack frames for itself.
This is incorrect behaviour, and also leads to "skip" doing the wrong
thing (which is the number of stack frames to avoid recording.)

Perversely, it does the right thing when passed a non-current thread.  Fix
this by ensuring that we have a known constant number of frames above the
main stack trace function, and always skip these.

Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
While debugging the FEC ethernet driver using stacktrace, it was noticed
that the stacktraces always begin as follows:

 [&lt;c00117b4&gt;] save_stack_trace_tsk+0x0/0x98
 [&lt;c0011870&gt;] save_stack_trace+0x24/0x28
 ...

This is because the stack trace code includes the stack frames for itself.
This is incorrect behaviour, and also leads to "skip" doing the wrong
thing (which is the number of stack frames to avoid recording.)

Perversely, it does the right thing when passed a non-current thread.  Fix
this by ensuring that we have a known constant number of frames above the
main stack trace function, and always skip these.

Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: 7913/1: fix framepointer check in unwind_frame</title>
<updated>2013-12-09T23:24:33+00:00</updated>
<author>
<name>Konstantin Khlebnikov</name>
<email>k.khlebnikov@samsung.com</email>
</author>
<published>2013-12-05T13:23:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=3abb6671a9c04479c4bd026798a05f857393b7e2'/>
<id>3abb6671a9c04479c4bd026798a05f857393b7e2</id>
<content type='text'>
This patch fixes corner case when (fp + 4) overflows unsigned long,
for example: fp = 0xFFFFFFFF -&gt; fp + 4 == 3.

Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Konstantin Khlebnikov &lt;k.khlebnikov@samsung.com&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch fixes corner case when (fp + 4) overflows unsigned long,
for example: fp = 0xFFFFFFFF -&gt; fp + 4 == 3.

Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Konstantin Khlebnikov &lt;k.khlebnikov@samsung.com&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>arm: convert core files from module.h to export.h</title>
<updated>2011-10-31T23:30:49+00:00</updated>
<author>
<name>Paul Gortmaker</name>
<email>paul.gortmaker@windriver.com</email>
</author>
<published>2011-07-22T14:58:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ecea4ab6d3d8bb4122522398200f1cd2a06af6d5'/>
<id>ecea4ab6d3d8bb4122522398200f1cd2a06af6d5</id>
<content type='text'>
Many of the core ARM kernel files are not modules, but just
including module.h for exporting symbols.  Now these files can
use the lighter footprint export.h for this role.

There are probably lots more, but ARM files of mach-* and plat-*
don't get coverage via a simple yesconfig build.  They will have
to be cleaned up and tested via using their respective configs.

Signed-off-by: Paul Gortmaker &lt;paul.gortmaker@windriver.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Many of the core ARM kernel files are not modules, but just
including module.h for exporting symbols.  Now these files can
use the lighter footprint export.h for this role.

There are probably lots more, but ARM files of mach-* and plat-*
don't get coverage via a simple yesconfig build.  They will have
to be cleaned up and tested via using their respective configs.

Signed-off-by: Paul Gortmaker &lt;paul.gortmaker@windriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: fix /proc/$PID/stack on SMP</title>
<updated>2011-01-15T09:27:04+00:00</updated>
<author>
<name>Russell King</name>
<email>rmk+kernel@arm.linux.org.uk</email>
</author>
<published>2011-01-15T09:27:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=d5996b2ff0e26cf7ed4c103084a2d6fc569e7216'/>
<id>d5996b2ff0e26cf7ed4c103084a2d6fc569e7216</id>
<content type='text'>
Rabin Vincent reports:
| On SMP, this BUG() in save_stack_trace_tsk() can be easily triggered
| from user space by reading /proc/$PID/stack, where $PID is any pid but
| the current process:
|
|	if (tsk != current) {
| #ifdef CONFIG_SMP
|		/*
|		 * What guarantees do we have here that 'tsk'
|		 * is not running on another CPU?
|		 */
|		BUG();
| #else

Fix this by replacing the BUG() with an entry to terminate the stack
trace, returning an empty trace - I'd rather not expose the dwarf
unwinder to a volatile stack of a running thread.

Reported-by: Rabin Vincent &lt;rabin@rab.in&gt;
Tested-by: Rabin Vincent &lt;rabin@rab.in&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Rabin Vincent reports:
| On SMP, this BUG() in save_stack_trace_tsk() can be easily triggered
| from user space by reading /proc/$PID/stack, where $PID is any pid but
| the current process:
|
|	if (tsk != current) {
| #ifdef CONFIG_SMP
|		/*
|		 * What guarantees do we have here that 'tsk'
|		 * is not running on another CPU?
|		 */
|		BUG();
| #else

Fix this by replacing the BUG() with an entry to terminate the stack
trace, returning an empty trace - I'd rather not expose the dwarf
unwinder to a volatile stack of a running thread.

Reported-by: Rabin Vincent &lt;rabin@rab.in&gt;
Tested-by: Rabin Vincent &lt;rabin@rab.in&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</pre>
</div>
</content>
</entry>
</feed>
