<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/arch/riscv/kernel/stacktrace.c, branch v6.9</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>riscv: Use READ_ONCE_NOCHECK in imprecise unwinding stack mode</title>
<updated>2023-03-09T22:50:35+00:00</updated>
<author>
<name>Alexandre Ghiti</name>
<email>alexghiti@rivosinc.com</email>
</author>
<published>2023-03-08T09:16:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=76950340cf03b149412fe0d5f0810e52ac1df8cb'/>
<id>76950340cf03b149412fe0d5f0810e52ac1df8cb</id>
<content type='text'>
When CONFIG_FRAME_POINTER is unset, the stack unwinding function
walk_stackframe randomly reads the stack and then, when KASAN is enabled,
it can lead to the following backtrace:

[    0.000000] ==================================================================
[    0.000000] BUG: KASAN: stack-out-of-bounds in walk_stackframe+0xa6/0x11a
[    0.000000] Read of size 8 at addr ffffffff81807c40 by task swapper/0
[    0.000000]
[    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 6.2.0-12919-g24203e6db61f #43
[    0.000000] Hardware name: riscv-virtio,qemu (DT)
[    0.000000] Call Trace:
[    0.000000] [&lt;ffffffff80007ba8&gt;] walk_stackframe+0x0/0x11a
[    0.000000] [&lt;ffffffff80099ecc&gt;] init_param_lock+0x26/0x2a
[    0.000000] [&lt;ffffffff80007c4a&gt;] walk_stackframe+0xa2/0x11a
[    0.000000] [&lt;ffffffff80c49c80&gt;] dump_stack_lvl+0x22/0x36
[    0.000000] [&lt;ffffffff80c3783e&gt;] print_report+0x198/0x4a8
[    0.000000] [&lt;ffffffff80099ecc&gt;] init_param_lock+0x26/0x2a
[    0.000000] [&lt;ffffffff80007c4a&gt;] walk_stackframe+0xa2/0x11a
[    0.000000] [&lt;ffffffff8015f68a&gt;] kasan_report+0x9a/0xc8
[    0.000000] [&lt;ffffffff80007c4a&gt;] walk_stackframe+0xa2/0x11a
[    0.000000] [&lt;ffffffff80007c4a&gt;] walk_stackframe+0xa2/0x11a
[    0.000000] [&lt;ffffffff8006e99c&gt;] desc_make_final+0x80/0x84
[    0.000000] [&lt;ffffffff8009a04e&gt;] stack_trace_save+0x88/0xa6
[    0.000000] [&lt;ffffffff80099fc2&gt;] filter_irq_stacks+0x72/0x76
[    0.000000] [&lt;ffffffff8006b95e&gt;] devkmsg_read+0x32a/0x32e
[    0.000000] [&lt;ffffffff8015ec16&gt;] kasan_save_stack+0x28/0x52
[    0.000000] [&lt;ffffffff8006e998&gt;] desc_make_final+0x7c/0x84
[    0.000000] [&lt;ffffffff8009a04a&gt;] stack_trace_save+0x84/0xa6
[    0.000000] [&lt;ffffffff8015ec52&gt;] kasan_set_track+0x12/0x20
[    0.000000] [&lt;ffffffff8015f22e&gt;] __kasan_slab_alloc+0x58/0x5e
[    0.000000] [&lt;ffffffff8015e7ea&gt;] __kmem_cache_create+0x21e/0x39a
[    0.000000] [&lt;ffffffff80e133ac&gt;] create_boot_cache+0x70/0x9c
[    0.000000] [&lt;ffffffff80e17ab2&gt;] kmem_cache_init+0x6c/0x11e
[    0.000000] [&lt;ffffffff80e00fd6&gt;] mm_init+0xd8/0xfe
[    0.000000] [&lt;ffffffff80e011d8&gt;] start_kernel+0x190/0x3ca
[    0.000000]
[    0.000000] The buggy address belongs to stack of task swapper/0
[    0.000000]  and is located at offset 0 in frame:
[    0.000000]  stack_trace_save+0x0/0xa6
[    0.000000]
[    0.000000] This frame has 1 object:
[    0.000000]  [32, 56) 'c'
[    0.000000]
[    0.000000] The buggy address belongs to the physical page:
[    0.000000] page:(____ptrval____) refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x81a07
[    0.000000] flags: 0x1000(reserved|zone=0)
[    0.000000] raw: 0000000000001000 ff600003f1e3d150 ff600003f1e3d150 0000000000000000
[    0.000000] raw: 0000000000000000 0000000000000000 00000001ffffffff
[    0.000000] page dumped because: kasan: bad access detected
[    0.000000]
[    0.000000] Memory state around the buggy address:
[    0.000000]  ffffffff81807b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    0.000000]  ffffffff81807b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    0.000000] &gt;ffffffff81807c00: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 f3
[    0.000000]                                            ^
[    0.000000]  ffffffff81807c80: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
[    0.000000]  ffffffff81807d00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    0.000000] ==================================================================

Fix that by using READ_ONCE_NOCHECK when reading the stack in imprecise
mode.

Fixes: 5d8544e2d007 ("RISC-V: Generic library routines and assembly")
Reported-by: Chathura Rajapaksha &lt;chathura.abeyrathne.lk@gmail.com&gt;
Link: https://lore.kernel.org/all/CAD7mqryDQCYyJ1gAmtMm8SASMWAQ4i103ptTb0f6Oda=tPY2=A@mail.gmail.com/
Suggested-by: Dmitry Vyukov &lt;dvyukov@google.com&gt;
Signed-off-by: Alexandre Ghiti &lt;alexghiti@rivosinc.com&gt;
Link: https://lore.kernel.org/r/20230308091639.602024-1-alexghiti@rivosinc.com
Signed-off-by: Palmer Dabbelt &lt;palmer@rivosinc.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When CONFIG_FRAME_POINTER is unset, the stack unwinding function
walk_stackframe randomly reads the stack and then, when KASAN is enabled,
it can lead to the following backtrace:

[    0.000000] ==================================================================
[    0.000000] BUG: KASAN: stack-out-of-bounds in walk_stackframe+0xa6/0x11a
[    0.000000] Read of size 8 at addr ffffffff81807c40 by task swapper/0
[    0.000000]
[    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 6.2.0-12919-g24203e6db61f #43
[    0.000000] Hardware name: riscv-virtio,qemu (DT)
[    0.000000] Call Trace:
[    0.000000] [&lt;ffffffff80007ba8&gt;] walk_stackframe+0x0/0x11a
[    0.000000] [&lt;ffffffff80099ecc&gt;] init_param_lock+0x26/0x2a
[    0.000000] [&lt;ffffffff80007c4a&gt;] walk_stackframe+0xa2/0x11a
[    0.000000] [&lt;ffffffff80c49c80&gt;] dump_stack_lvl+0x22/0x36
[    0.000000] [&lt;ffffffff80c3783e&gt;] print_report+0x198/0x4a8
[    0.000000] [&lt;ffffffff80099ecc&gt;] init_param_lock+0x26/0x2a
[    0.000000] [&lt;ffffffff80007c4a&gt;] walk_stackframe+0xa2/0x11a
[    0.000000] [&lt;ffffffff8015f68a&gt;] kasan_report+0x9a/0xc8
[    0.000000] [&lt;ffffffff80007c4a&gt;] walk_stackframe+0xa2/0x11a
[    0.000000] [&lt;ffffffff80007c4a&gt;] walk_stackframe+0xa2/0x11a
[    0.000000] [&lt;ffffffff8006e99c&gt;] desc_make_final+0x80/0x84
[    0.000000] [&lt;ffffffff8009a04e&gt;] stack_trace_save+0x88/0xa6
[    0.000000] [&lt;ffffffff80099fc2&gt;] filter_irq_stacks+0x72/0x76
[    0.000000] [&lt;ffffffff8006b95e&gt;] devkmsg_read+0x32a/0x32e
[    0.000000] [&lt;ffffffff8015ec16&gt;] kasan_save_stack+0x28/0x52
[    0.000000] [&lt;ffffffff8006e998&gt;] desc_make_final+0x7c/0x84
[    0.000000] [&lt;ffffffff8009a04a&gt;] stack_trace_save+0x84/0xa6
[    0.000000] [&lt;ffffffff8015ec52&gt;] kasan_set_track+0x12/0x20
[    0.000000] [&lt;ffffffff8015f22e&gt;] __kasan_slab_alloc+0x58/0x5e
[    0.000000] [&lt;ffffffff8015e7ea&gt;] __kmem_cache_create+0x21e/0x39a
[    0.000000] [&lt;ffffffff80e133ac&gt;] create_boot_cache+0x70/0x9c
[    0.000000] [&lt;ffffffff80e17ab2&gt;] kmem_cache_init+0x6c/0x11e
[    0.000000] [&lt;ffffffff80e00fd6&gt;] mm_init+0xd8/0xfe
[    0.000000] [&lt;ffffffff80e011d8&gt;] start_kernel+0x190/0x3ca
[    0.000000]
[    0.000000] The buggy address belongs to stack of task swapper/0
[    0.000000]  and is located at offset 0 in frame:
[    0.000000]  stack_trace_save+0x0/0xa6
[    0.000000]
[    0.000000] This frame has 1 object:
[    0.000000]  [32, 56) 'c'
[    0.000000]
[    0.000000] The buggy address belongs to the physical page:
[    0.000000] page:(____ptrval____) refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x81a07
[    0.000000] flags: 0x1000(reserved|zone=0)
[    0.000000] raw: 0000000000001000 ff600003f1e3d150 ff600003f1e3d150 0000000000000000
[    0.000000] raw: 0000000000000000 0000000000000000 00000001ffffffff
[    0.000000] page dumped because: kasan: bad access detected
[    0.000000]
[    0.000000] Memory state around the buggy address:
[    0.000000]  ffffffff81807b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    0.000000]  ffffffff81807b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    0.000000] &gt;ffffffff81807c00: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 f3
[    0.000000]                                            ^
[    0.000000]  ffffffff81807c80: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
[    0.000000]  ffffffff81807d00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[    0.000000] ==================================================================

Fix that by using READ_ONCE_NOCHECK when reading the stack in imprecise
mode.

Fixes: 5d8544e2d007 ("RISC-V: Generic library routines and assembly")
Reported-by: Chathura Rajapaksha &lt;chathura.abeyrathne.lk@gmail.com&gt;
Link: https://lore.kernel.org/all/CAD7mqryDQCYyJ1gAmtMm8SASMWAQ4i103ptTb0f6Oda=tPY2=A@mail.gmail.com/
Suggested-by: Dmitry Vyukov &lt;dvyukov@google.com&gt;
Signed-off-by: Alexandre Ghiti &lt;alexghiti@rivosinc.com&gt;
Link: https://lore.kernel.org/r/20230308091639.602024-1-alexghiti@rivosinc.com
Signed-off-by: Palmer Dabbelt &lt;palmer@rivosinc.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>riscv: stacktrace: Fix missing the first frame</title>
<updated>2023-02-03T03:33:05+00:00</updated>
<author>
<name>Liu Shixin</name>
<email>liushixin2@huawei.com</email>
</author>
<published>2022-12-07T02:50:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=cb80242cc679d6397e77d8a964deeb3ff218d2b5'/>
<id>cb80242cc679d6397e77d8a964deeb3ff218d2b5</id>
<content type='text'>
When running kfence_test, I found some testcases failed like this:

 # test_out_of_bounds_read: EXPECTATION FAILED at mm/kfence/kfence_test.c:346
 Expected report_matches(&amp;expect) to be true, but is false
 not ok 1 - test_out_of_bounds_read

The corresponding call-trace is:

 BUG: KFENCE: out-of-bounds read in kunit_try_run_case+0x38/0x84

 Out-of-bounds read at 0x(____ptrval____) (32B right of kfence-#10):
  kunit_try_run_case+0x38/0x84
  kunit_generic_run_threadfn_adapter+0x12/0x1e
  kthread+0xc8/0xde
  ret_from_exception+0x0/0xc

The kfence_test using the first frame of call trace to check whether the
testcase is succeed or not. Commit 6a00ef449370 ("riscv: eliminate
unreliable __builtin_frame_address(1)") skip first frame for all
case, which results the kfence_test failed. Indeed, we only need to skip
the first frame for case (task==NULL || task==current).

With this patch, the call-trace will be:

 BUG: KFENCE: out-of-bounds read in test_out_of_bounds_read+0x88/0x19e

 Out-of-bounds read at 0x(____ptrval____) (1B left of kfence-#7):
  test_out_of_bounds_read+0x88/0x19e
  kunit_try_run_case+0x38/0x84
  kunit_generic_run_threadfn_adapter+0x12/0x1e
  kthread+0xc8/0xde
  ret_from_exception+0x0/0xc

Fixes: 6a00ef449370 ("riscv: eliminate unreliable __builtin_frame_address(1)")
Signed-off-by: Liu Shixin &lt;liushixin2@huawei.com&gt;
Tested-by: Samuel Holland &lt;samuel@sholland.org&gt;
Link: https://lore.kernel.org/r/20221207025038.1022045-1-liushixin2@huawei.com
Signed-off-by: Palmer Dabbelt &lt;palmer@rivosinc.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When running kfence_test, I found some testcases failed like this:

 # test_out_of_bounds_read: EXPECTATION FAILED at mm/kfence/kfence_test.c:346
 Expected report_matches(&amp;expect) to be true, but is false
 not ok 1 - test_out_of_bounds_read

The corresponding call-trace is:

 BUG: KFENCE: out-of-bounds read in kunit_try_run_case+0x38/0x84

 Out-of-bounds read at 0x(____ptrval____) (32B right of kfence-#10):
  kunit_try_run_case+0x38/0x84
  kunit_generic_run_threadfn_adapter+0x12/0x1e
  kthread+0xc8/0xde
  ret_from_exception+0x0/0xc

The kfence_test using the first frame of call trace to check whether the
testcase is succeed or not. Commit 6a00ef449370 ("riscv: eliminate
unreliable __builtin_frame_address(1)") skip first frame for all
case, which results the kfence_test failed. Indeed, we only need to skip
the first frame for case (task==NULL || task==current).

With this patch, the call-trace will be:

 BUG: KFENCE: out-of-bounds read in test_out_of_bounds_read+0x88/0x19e

 Out-of-bounds read at 0x(____ptrval____) (1B left of kfence-#7):
  test_out_of_bounds_read+0x88/0x19e
  kunit_try_run_case+0x38/0x84
  kunit_generic_run_threadfn_adapter+0x12/0x1e
  kthread+0xc8/0xde
  ret_from_exception+0x0/0xc

Fixes: 6a00ef449370 ("riscv: eliminate unreliable __builtin_frame_address(1)")
Signed-off-by: Liu Shixin &lt;liushixin2@huawei.com&gt;
Tested-by: Samuel Holland &lt;samuel@sholland.org&gt;
Link: https://lore.kernel.org/r/20221207025038.1022045-1-liushixin2@huawei.com
Signed-off-by: Palmer Dabbelt &lt;palmer@rivosinc.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>riscv: stacktrace: Make walk_stackframe cross pt_regs frame</title>
<updated>2022-12-06T02:13:34+00:00</updated>
<author>
<name>Guo Ren</name>
<email>guoren@linux.alibaba.com</email>
</author>
<published>2022-11-09T06:49:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=7ecdadf7f8c659524f6b2aebf6be7bf619764d90'/>
<id>7ecdadf7f8c659524f6b2aebf6be7bf619764d90</id>
<content type='text'>
The current walk_stackframe with FRAME_POINTER would stop unwinding at
ret_from_exception:
  BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1518
  in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 1, name: init
  CPU: 0 PID: 1 Comm: init Not tainted 5.10.113-00021-g15c15974895c-dirty #192
  Call Trace:
  [&lt;ffffffe0002038c8&gt;] walk_stackframe+0x0/0xee
  [&lt;ffffffe000aecf48&gt;] show_stack+0x32/0x4a
  [&lt;ffffffe000af1618&gt;] dump_stack_lvl+0x72/0x8e
  [&lt;ffffffe000af1648&gt;] dump_stack+0x14/0x1c
  [&lt;ffffffe000239ad2&gt;] ___might_sleep+0x12e/0x138
  [&lt;ffffffe000239aec&gt;] __might_sleep+0x10/0x18
  [&lt;ffffffe000afe3fe&gt;] down_read+0x22/0xa4
  [&lt;ffffffe000207588&gt;] do_page_fault+0xb0/0x2fe
  [&lt;ffffffe000201b80&gt;] ret_from_exception+0x0/0xc

The optimization would help walk_stackframe cross the pt_regs frame and
get more backtrace of debug info:
  BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1518
  in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 1, name: init
  CPU: 0 PID: 1 Comm: init Not tainted 5.10.113-00021-g15c15974895c-dirty #192
  Call Trace:
  [&lt;ffffffe0002038c8&gt;] walk_stackframe+0x0/0xee
  [&lt;ffffffe000aecf48&gt;] show_stack+0x32/0x4a
  [&lt;ffffffe000af1618&gt;] dump_stack_lvl+0x72/0x8e
  [&lt;ffffffe000af1648&gt;] dump_stack+0x14/0x1c
  [&lt;ffffffe000239ad2&gt;] ___might_sleep+0x12e/0x138
  [&lt;ffffffe000239aec&gt;] __might_sleep+0x10/0x18
  [&lt;ffffffe000afe3fe&gt;] down_read+0x22/0xa4
  [&lt;ffffffe000207588&gt;] do_page_fault+0xb0/0x2fe
  [&lt;ffffffe000201b80&gt;] ret_from_exception+0x0/0xc
  [&lt;ffffffe000613c06&gt;] riscv_intc_irq+0x1a/0x72
  [&lt;ffffffe000201b80&gt;] ret_from_exception+0x0/0xc
  [&lt;ffffffe00033f44a&gt;] vma_link+0x54/0x160
  [&lt;ffffffe000341d7a&gt;] mmap_region+0x2cc/0x4d0
  [&lt;ffffffe000342256&gt;] do_mmap+0x2d8/0x3ac
  [&lt;ffffffe000326318&gt;] vm_mmap_pgoff+0x70/0xb8
  [&lt;ffffffe00032638a&gt;] vm_mmap+0x2a/0x36
  [&lt;ffffffe0003cfdde&gt;] elf_map+0x72/0x84
  [&lt;ffffffe0003d05f8&gt;] load_elf_binary+0x69a/0xec8
  [&lt;ffffffe000376240&gt;] bprm_execve+0x246/0x53a
  [&lt;ffffffe00037786c&gt;] kernel_execve+0xe8/0x124
  [&lt;ffffffe000aecdf2&gt;] run_init_process+0xfa/0x10c
  [&lt;ffffffe000aece16&gt;] try_to_run_init_process+0x12/0x3c
  [&lt;ffffffe000afa920&gt;] kernel_init+0xb4/0xf8
  [&lt;ffffffe000201b80&gt;] ret_from_exception+0x0/0xc

Here is the error injection test code for the above output:
 drivers/irqchip/irq-riscv-intc.c:
 static asmlinkage void riscv_intc_irq(struct pt_regs *regs)
 {
        unsigned long cause = regs-&gt;cause &amp; ~CAUSE_IRQ_FLAG;
+       u32 tmp; __get_user(tmp, (u32 *)0);

Signed-off-by: Guo Ren &lt;guoren@linux.alibaba.com&gt;
Signed-off-by: Guo Ren &lt;guoren@kernel.org&gt;
Link: https://lore.kernel.org/r/20221109064937.3643993-3-guoren@kernel.org
[Palmer: use SYM_CODE_*]
Signed-off-by: Palmer Dabbelt &lt;palmer@rivosinc.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The current walk_stackframe with FRAME_POINTER would stop unwinding at
ret_from_exception:
  BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1518
  in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 1, name: init
  CPU: 0 PID: 1 Comm: init Not tainted 5.10.113-00021-g15c15974895c-dirty #192
  Call Trace:
  [&lt;ffffffe0002038c8&gt;] walk_stackframe+0x0/0xee
  [&lt;ffffffe000aecf48&gt;] show_stack+0x32/0x4a
  [&lt;ffffffe000af1618&gt;] dump_stack_lvl+0x72/0x8e
  [&lt;ffffffe000af1648&gt;] dump_stack+0x14/0x1c
  [&lt;ffffffe000239ad2&gt;] ___might_sleep+0x12e/0x138
  [&lt;ffffffe000239aec&gt;] __might_sleep+0x10/0x18
  [&lt;ffffffe000afe3fe&gt;] down_read+0x22/0xa4
  [&lt;ffffffe000207588&gt;] do_page_fault+0xb0/0x2fe
  [&lt;ffffffe000201b80&gt;] ret_from_exception+0x0/0xc

The optimization would help walk_stackframe cross the pt_regs frame and
get more backtrace of debug info:
  BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1518
  in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 1, name: init
  CPU: 0 PID: 1 Comm: init Not tainted 5.10.113-00021-g15c15974895c-dirty #192
  Call Trace:
  [&lt;ffffffe0002038c8&gt;] walk_stackframe+0x0/0xee
  [&lt;ffffffe000aecf48&gt;] show_stack+0x32/0x4a
  [&lt;ffffffe000af1618&gt;] dump_stack_lvl+0x72/0x8e
  [&lt;ffffffe000af1648&gt;] dump_stack+0x14/0x1c
  [&lt;ffffffe000239ad2&gt;] ___might_sleep+0x12e/0x138
  [&lt;ffffffe000239aec&gt;] __might_sleep+0x10/0x18
  [&lt;ffffffe000afe3fe&gt;] down_read+0x22/0xa4
  [&lt;ffffffe000207588&gt;] do_page_fault+0xb0/0x2fe
  [&lt;ffffffe000201b80&gt;] ret_from_exception+0x0/0xc
  [&lt;ffffffe000613c06&gt;] riscv_intc_irq+0x1a/0x72
  [&lt;ffffffe000201b80&gt;] ret_from_exception+0x0/0xc
  [&lt;ffffffe00033f44a&gt;] vma_link+0x54/0x160
  [&lt;ffffffe000341d7a&gt;] mmap_region+0x2cc/0x4d0
  [&lt;ffffffe000342256&gt;] do_mmap+0x2d8/0x3ac
  [&lt;ffffffe000326318&gt;] vm_mmap_pgoff+0x70/0xb8
  [&lt;ffffffe00032638a&gt;] vm_mmap+0x2a/0x36
  [&lt;ffffffe0003cfdde&gt;] elf_map+0x72/0x84
  [&lt;ffffffe0003d05f8&gt;] load_elf_binary+0x69a/0xec8
  [&lt;ffffffe000376240&gt;] bprm_execve+0x246/0x53a
  [&lt;ffffffe00037786c&gt;] kernel_execve+0xe8/0x124
  [&lt;ffffffe000aecdf2&gt;] run_init_process+0xfa/0x10c
  [&lt;ffffffe000aece16&gt;] try_to_run_init_process+0x12/0x3c
  [&lt;ffffffe000afa920&gt;] kernel_init+0xb4/0xf8
  [&lt;ffffffe000201b80&gt;] ret_from_exception+0x0/0xc

Here is the error injection test code for the above output:
 drivers/irqchip/irq-riscv-intc.c:
 static asmlinkage void riscv_intc_irq(struct pt_regs *regs)
 {
        unsigned long cause = regs-&gt;cause &amp; ~CAUSE_IRQ_FLAG;
+       u32 tmp; __get_user(tmp, (u32 *)0);

Signed-off-by: Guo Ren &lt;guoren@linux.alibaba.com&gt;
Signed-off-by: Guo Ren &lt;guoren@kernel.org&gt;
Link: https://lore.kernel.org/r/20221109064937.3643993-3-guoren@kernel.org
[Palmer: use SYM_CODE_*]
Signed-off-by: Palmer Dabbelt &lt;palmer@rivosinc.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>riscv: stacktrace: Fixup ftrace_graph_ret_addr retp argument</title>
<updated>2022-12-06T00:58:01+00:00</updated>
<author>
<name>Guo Ren</name>
<email>guoren@linux.alibaba.com</email>
</author>
<published>2022-11-09T06:49:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=5c3022e4a616d800cf5f4c3a981d7992179e44a1'/>
<id>5c3022e4a616d800cf5f4c3a981d7992179e44a1</id>
<content type='text'>
The 'retp' is a pointer to the return address on the stack, so we
must pass the current return address pointer as the 'retp'
argument to ftrace_push_return_trace(). Not parent function's
return address on the stack.

Fixes: b785ec129bd9 ("riscv/ftrace: Add HAVE_FUNCTION_GRAPH_RET_ADDR_PTR support")
Signed-off-by: Guo Ren &lt;guoren@linux.alibaba.com&gt;
Signed-off-by: Guo Ren &lt;guoren@kernel.org&gt;
Link: https://lore.kernel.org/r/20221109064937.3643993-2-guoren@kernel.org
Cc: stable@vger.kernel.org
Signed-off-by: Palmer Dabbelt &lt;palmer@rivosinc.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The 'retp' is a pointer to the return address on the stack, so we
must pass the current return address pointer as the 'retp'
argument to ftrace_push_return_trace(). Not parent function's
return address on the stack.

Fixes: b785ec129bd9 ("riscv/ftrace: Add HAVE_FUNCTION_GRAPH_RET_ADDR_PTR support")
Signed-off-by: Guo Ren &lt;guoren@linux.alibaba.com&gt;
Signed-off-by: Guo Ren &lt;guoren@kernel.org&gt;
Link: https://lore.kernel.org/r/20221109064937.3643993-2-guoren@kernel.org
Cc: stable@vger.kernel.org
Signed-off-by: Palmer Dabbelt &lt;palmer@rivosinc.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>riscv: Rename "sp_in_global" to "current_stack_pointer"</title>
<updated>2022-03-30T22:15:27+00:00</updated>
<author>
<name>Kees Cook</name>
<email>keescook@chromium.org</email>
</author>
<published>2022-02-24T06:04:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=fdecfea09328b33fd08a4d418237cce9fd176d69'/>
<id>fdecfea09328b33fd08a4d418237cce9fd176d69</id>
<content type='text'>
To follow the existing per-arch conventions, rename "sp_in_global" to
"current_stack_pointer". This will let it be used in non-arch places
(like HARDENED_USERCOPY).

Signed-off-by: Kees Cook &lt;keescook@chromium.org&gt;
Signed-off-by: Palmer Dabbelt &lt;palmer@rivosinc.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
To follow the existing per-arch conventions, rename "sp_in_global" to
"current_stack_pointer". This will let it be used in non-arch places
(like HARDENED_USERCOPY).

Signed-off-by: Kees Cook &lt;keescook@chromium.org&gt;
Signed-off-by: Palmer Dabbelt &lt;palmer@rivosinc.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>riscv: eliminate unreliable __builtin_frame_address(1)</title>
<updated>2022-02-04T18:12:32+00:00</updated>
<author>
<name>Changbin Du</name>
<email>changbin.du@gmail.com</email>
</author>
<published>2022-01-17T15:44:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=6a00ef4493706a23120057fafbc62379bcde11ec'/>
<id>6a00ef4493706a23120057fafbc62379bcde11ec</id>
<content type='text'>
I tried different pieces of code which uses __builtin_frame_address(1)
(with both gcc version 7.5.0 and 10.3.0) to verify whether it works as
expected on riscv64. The result is negative.

What the compiler had generated is as below:
31                      fp = (unsigned long)__builtin_frame_address(1);
   0xffffffff80006024 &lt;+200&gt;:   ld      s1,0(s0)

It takes '0(s0)' as the address of frame 1 (caller), but the actual address
should be '-16(s0)'.

          |       ...       | &lt;-+
          +-----------------+   |
          | return address  |   |
          | previous fp     |   |
          | saved registers |   |
          | local variables |   |
  $fp --&gt; |       ...       |   |
          +-----------------+   |
          | return address  |   |
          | previous fp --------+
          | saved registers |
  $sp --&gt; | local variables |
          +-----------------+

This leads the kernel can not dump the full stack trace on riscv.

[    7.222126][    T1] Call Trace:
[    7.222804][    T1] [&lt;ffffffff80006058&gt;] dump_backtrace+0x2c/0x3a

This problem is not exposed on most riscv builds just because the '0(s0)'
occasionally is the address frame 2 (caller's caller), if only ra and fp
are stored in frame 1 (caller).

          |       ...       | &lt;-+
          +-----------------+   |
          | return address  |   |
  $fp --&gt; | previous fp     |   |
          +-----------------+   |
          | return address  |   |
          | previous fp --------+
          | saved registers |
  $sp --&gt; | local variables |
          +-----------------+

This could be a *bug* of gcc that should be fixed. But as noted in gcc
manual "Calling this function with a nonzero argument can have
unpredictable effects, including crashing the calling program.", let's
remove the '__builtin_frame_address(1)' in backtrace code.

With this fix now it can show full stack trace:
[   10.444838][    T1] Call Trace:
[   10.446199][    T1] [&lt;ffffffff8000606c&gt;] dump_backtrace+0x2c/0x3a
[   10.447711][    T1] [&lt;ffffffff800060ac&gt;] show_stack+0x32/0x3e
[   10.448710][    T1] [&lt;ffffffff80a005c0&gt;] dump_stack_lvl+0x58/0x7a
[   10.449941][    T1] [&lt;ffffffff80a005f6&gt;] dump_stack+0x14/0x1c
[   10.450929][    T1] [&lt;ffffffff804c04ee&gt;] ubsan_epilogue+0x10/0x5a
[   10.451869][    T1] [&lt;ffffffff804c092e&gt;] __ubsan_handle_load_invalid_value+0x6c/0x78
[   10.453049][    T1] [&lt;ffffffff8018f834&gt;] __pagevec_release+0x62/0x64
[   10.455476][    T1] [&lt;ffffffff80190830&gt;] truncate_inode_pages_range+0x132/0x5be
[   10.456798][    T1] [&lt;ffffffff80190ce0&gt;] truncate_inode_pages+0x24/0x30
[   10.457853][    T1] [&lt;ffffffff8045bb04&gt;] kill_bdev+0x32/0x3c
...

Signed-off-by: Changbin Du &lt;changbin.du@gmail.com&gt;
Fixes: eac2f3059e02 ("riscv: stacktrace: fix the riscv stacktrace when CONFIG_FRAME_POINTER enabled")
Cc: stable@vger.kernel.org
Signed-off-by: Palmer Dabbelt &lt;palmer@rivosinc.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
I tried different pieces of code which uses __builtin_frame_address(1)
(with both gcc version 7.5.0 and 10.3.0) to verify whether it works as
expected on riscv64. The result is negative.

What the compiler had generated is as below:
31                      fp = (unsigned long)__builtin_frame_address(1);
   0xffffffff80006024 &lt;+200&gt;:   ld      s1,0(s0)

It takes '0(s0)' as the address of frame 1 (caller), but the actual address
should be '-16(s0)'.

          |       ...       | &lt;-+
          +-----------------+   |
          | return address  |   |
          | previous fp     |   |
          | saved registers |   |
          | local variables |   |
  $fp --&gt; |       ...       |   |
          +-----------------+   |
          | return address  |   |
          | previous fp --------+
          | saved registers |
  $sp --&gt; | local variables |
          +-----------------+

This leads the kernel can not dump the full stack trace on riscv.

[    7.222126][    T1] Call Trace:
[    7.222804][    T1] [&lt;ffffffff80006058&gt;] dump_backtrace+0x2c/0x3a

This problem is not exposed on most riscv builds just because the '0(s0)'
occasionally is the address frame 2 (caller's caller), if only ra and fp
are stored in frame 1 (caller).

          |       ...       | &lt;-+
          +-----------------+   |
          | return address  |   |
  $fp --&gt; | previous fp     |   |
          +-----------------+   |
          | return address  |   |
          | previous fp --------+
          | saved registers |
  $sp --&gt; | local variables |
          +-----------------+

This could be a *bug* of gcc that should be fixed. But as noted in gcc
manual "Calling this function with a nonzero argument can have
unpredictable effects, including crashing the calling program.", let's
remove the '__builtin_frame_address(1)' in backtrace code.

With this fix now it can show full stack trace:
[   10.444838][    T1] Call Trace:
[   10.446199][    T1] [&lt;ffffffff8000606c&gt;] dump_backtrace+0x2c/0x3a
[   10.447711][    T1] [&lt;ffffffff800060ac&gt;] show_stack+0x32/0x3e
[   10.448710][    T1] [&lt;ffffffff80a005c0&gt;] dump_stack_lvl+0x58/0x7a
[   10.449941][    T1] [&lt;ffffffff80a005f6&gt;] dump_stack+0x14/0x1c
[   10.450929][    T1] [&lt;ffffffff804c04ee&gt;] ubsan_epilogue+0x10/0x5a
[   10.451869][    T1] [&lt;ffffffff804c092e&gt;] __ubsan_handle_load_invalid_value+0x6c/0x78
[   10.453049][    T1] [&lt;ffffffff8018f834&gt;] __pagevec_release+0x62/0x64
[   10.455476][    T1] [&lt;ffffffff80190830&gt;] truncate_inode_pages_range+0x132/0x5be
[   10.456798][    T1] [&lt;ffffffff80190ce0&gt;] truncate_inode_pages+0x24/0x30
[   10.457853][    T1] [&lt;ffffffff8045bb04&gt;] kill_bdev+0x32/0x3c
...

Signed-off-by: Changbin Du &lt;changbin.du@gmail.com&gt;
Fixes: eac2f3059e02 ("riscv: stacktrace: fix the riscv stacktrace when CONFIG_FRAME_POINTER enabled")
Cc: stable@vger.kernel.org
Signed-off-by: Palmer Dabbelt &lt;palmer@rivosinc.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>arch: Make ARCH_STACKWALK independent of STACKTRACE</title>
<updated>2021-12-10T14:06:03+00:00</updated>
<author>
<name>Peter Zijlstra</name>
<email>peterz@infradead.org</email>
</author>
<published>2021-11-29T14:28:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=1614b2b11fab29dd4ff31ebba9d266961f5af69e'/>
<id>1614b2b11fab29dd4ff31ebba9d266961f5af69e</id>
<content type='text'>
Make arch_stack_walk() available for ARCH_STACKWALK architectures
without it being entangled in STACKTRACE.

Link: https://lore.kernel.org/lkml/20211022152104.356586621@infradead.org/
Signed-off-by: Peter Zijlstra (Intel) &lt;peterz@infradead.org&gt;
[Mark: rebase, drop unnecessary arm change]
Signed-off-by: Mark Rutland &lt;mark.rutland@arm.com&gt;
Cc: Albert Ou &lt;aou@eecs.berkeley.edu&gt;
Cc: Borislav Petkov &lt;bp@alien8.de&gt;
Cc: Christian Borntraeger &lt;borntraeger@de.ibm.com&gt;
Cc: Dave Hansen &lt;dave.hansen@linux.intel.com&gt;
Cc: Heiko Carstens &lt;hca@linux.ibm.com&gt;
Cc: Ingo Molnar &lt;mingo@redhat.com&gt;
Cc: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Cc: Palmer Dabbelt &lt;palmer@dabbelt.com&gt;
Cc: Paul Walmsley &lt;paul.walmsley@sifive.com&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: Vasily Gorbik &lt;gor@linux.ibm.com&gt;
Link: https://lore.kernel.org/r/20211129142849.3056714-2-mark.rutland@arm.com
Signed-off-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Make arch_stack_walk() available for ARCH_STACKWALK architectures
without it being entangled in STACKTRACE.

Link: https://lore.kernel.org/lkml/20211022152104.356586621@infradead.org/
Signed-off-by: Peter Zijlstra (Intel) &lt;peterz@infradead.org&gt;
[Mark: rebase, drop unnecessary arm change]
Signed-off-by: Mark Rutland &lt;mark.rutland@arm.com&gt;
Cc: Albert Ou &lt;aou@eecs.berkeley.edu&gt;
Cc: Borislav Petkov &lt;bp@alien8.de&gt;
Cc: Christian Borntraeger &lt;borntraeger@de.ibm.com&gt;
Cc: Dave Hansen &lt;dave.hansen@linux.intel.com&gt;
Cc: Heiko Carstens &lt;hca@linux.ibm.com&gt;
Cc: Ingo Molnar &lt;mingo@redhat.com&gt;
Cc: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Cc: Palmer Dabbelt &lt;palmer@dabbelt.com&gt;
Cc: Paul Walmsley &lt;paul.walmsley@sifive.com&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: Vasily Gorbik &lt;gor@linux.ibm.com&gt;
Link: https://lore.kernel.org/r/20211129142849.3056714-2-mark.rutland@arm.com
Signed-off-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>sched: Add wrapper for get_wchan() to keep task blocked</title>
<updated>2021-10-15T09:25:14+00:00</updated>
<author>
<name>Kees Cook</name>
<email>keescook@chromium.org</email>
</author>
<published>2021-09-29T22:02:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=42a20f86dc19f9282d974df0ba4d226c865ab9dd'/>
<id>42a20f86dc19f9282d974df0ba4d226c865ab9dd</id>
<content type='text'>
Having a stable wchan means the process must be blocked and for it to
stay that way while performing stack unwinding.

Suggested-by: Peter Zijlstra &lt;peterz@infradead.org&gt;
Signed-off-by: Kees Cook &lt;keescook@chromium.org&gt;
Signed-off-by: Peter Zijlstra (Intel) &lt;peterz@infradead.org&gt;
Acked-by: Geert Uytterhoeven &lt;geert@linux-m68k.org&gt;
Acked-by: Russell King (Oracle) &lt;rmk+kernel@armlinux.org.uk&gt; [arm]
Tested-by: Mark Rutland &lt;mark.rutland@arm.com&gt; [arm64]
Link: https://lkml.kernel.org/r/20211008111626.332092234@infradead.org
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Having a stable wchan means the process must be blocked and for it to
stay that way while performing stack unwinding.

Suggested-by: Peter Zijlstra &lt;peterz@infradead.org&gt;
Signed-off-by: Kees Cook &lt;keescook@chromium.org&gt;
Signed-off-by: Peter Zijlstra (Intel) &lt;peterz@infradead.org&gt;
Acked-by: Geert Uytterhoeven &lt;geert@linux-m68k.org&gt;
Acked-by: Russell King (Oracle) &lt;rmk+kernel@armlinux.org.uk&gt; [arm]
Tested-by: Mark Rutland &lt;mark.rutland@arm.com&gt; [arm64]
Link: https://lkml.kernel.org/r/20211008111626.332092234@infradead.org
</pre>
</div>
</content>
</entry>
<entry>
<title>riscv: stacktrace: Fix NULL pointer dereference</title>
<updated>2021-07-24T19:58:51+00:00</updated>
<author>
<name>Jisheng Zhang</name>
<email>jszhang@kernel.org</email>
</author>
<published>2021-07-16T13:40:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=78d9d8005e4556448f398d876f29d0ca7ab8e398'/>
<id>78d9d8005e4556448f398d876f29d0ca7ab8e398</id>
<content type='text'>
When CONFIG_FRAME_POINTER=y, calling dump_stack() can always trigger
NULL pointer dereference panic similar as below:

[    0.396060] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.13.0-rc5+ #47
[    0.396692] Hardware name: riscv-virtio,qemu (DT)
[    0.397176] Call Trace:
[    0.398191] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000960
[    0.399487] Oops [#1]
[    0.399739] Modules linked in:
[    0.400135] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.13.0-rc5+ #47
[    0.400570] Hardware name: riscv-virtio,qemu (DT)
[    0.400926] epc : walk_stackframe+0xc4/0xdc
[    0.401291]  ra : dump_backtrace+0x30/0x38
[    0.401630] epc : ffffffff80004922 ra : ffffffff8000496a sp : ffffffe000f3bd00
[    0.402115]  gp : ffffffff80cfdcb8 tp : ffffffe000f30000 t0 : ffffffff80d0b0cf
[    0.402602]  t1 : ffffffff80d0b0c0 t2 : 0000000000000000 s0 : ffffffe000f3bd60
[    0.403071]  s1 : ffffffff808bc2e8 a0 : 0000000000001000 a1 : 0000000000000000
[    0.403448]  a2 : ffffffff803d7088 a3 : ffffffff808bc2e8 a4 : 6131725dbc24d400
[    0.403820]  a5 : 0000000000001000 a6 : 0000000000000002 a7 : ffffffffffffffff
[    0.404226]  s2 : 0000000000000000 s3 : 0000000000000000 s4 : 0000000000000000
[    0.404634]  s5 : ffffffff803d7088 s6 : ffffffff808bc2e8 s7 : ffffffff80630650
[    0.405085]  s8 : ffffffff80912a80 s9 : 0000000000000008 s10: ffffffff804000fc
[    0.405388]  s11: 0000000000000000 t3 : 0000000000000043 t4 : ffffffffffffffff
[    0.405616]  t5 : 000000000000003d t6 : ffffffe000f3baa8
[    0.405793] status: 0000000000000100 badaddr: 0000000000000960 cause: 000000000000000d
[    0.406135] [&lt;ffffffff80004922&gt;] walk_stackframe+0xc4/0xdc
[    0.407032] [&lt;ffffffff8000496a&gt;] dump_backtrace+0x30/0x38
[    0.407797] [&lt;ffffffff803d7100&gt;] show_stack+0x40/0x4c
[    0.408234] [&lt;ffffffff803d9e5c&gt;] dump_stack+0x90/0xb6
[    0.409019] [&lt;ffffffff8040423e&gt;] ptdump_init+0x20/0xc4
[    0.409681] [&lt;ffffffff800015b6&gt;] do_one_initcall+0x4c/0x226
[    0.410110] [&lt;ffffffff80401094&gt;] kernel_init_freeable+0x1f4/0x258
[    0.410562] [&lt;ffffffff803dba88&gt;] kernel_init+0x22/0x148
[    0.410959] [&lt;ffffffff800029e2&gt;] ret_from_exception+0x0/0x14
[    0.412241] ---[ end trace b2ab92c901b96251 ]---
[    0.413099] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b

The reason is the task is NULL when we finally call walk_stackframe()
the NULL is passed from __dump_stack():

|static void __dump_stack(void)
|{
|        dump_stack_print_info(KERN_DEFAULT);
|        show_stack(NULL, NULL, KERN_DEFAULT);
|}

Fix this issue by checking "task == NULL" case in walk_stackframe().

Fixes: eac2f3059e02 ("riscv: stacktrace: fix the riscv stacktrace when CONFIG_FRAME_POINTER enabled")
Signed-off-by: Jisheng Zhang &lt;jszhang@kernel.org&gt;
Reviewed-by: Atish Patra &lt;atish.patra@wdc.com&gt;
Tested-by: Wende Tan &lt;twd2.me@gmail.com&gt;
Signed-off-by: Palmer Dabbelt &lt;palmerdabbelt@google.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When CONFIG_FRAME_POINTER=y, calling dump_stack() can always trigger
NULL pointer dereference panic similar as below:

[    0.396060] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.13.0-rc5+ #47
[    0.396692] Hardware name: riscv-virtio,qemu (DT)
[    0.397176] Call Trace:
[    0.398191] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000960
[    0.399487] Oops [#1]
[    0.399739] Modules linked in:
[    0.400135] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.13.0-rc5+ #47
[    0.400570] Hardware name: riscv-virtio,qemu (DT)
[    0.400926] epc : walk_stackframe+0xc4/0xdc
[    0.401291]  ra : dump_backtrace+0x30/0x38
[    0.401630] epc : ffffffff80004922 ra : ffffffff8000496a sp : ffffffe000f3bd00
[    0.402115]  gp : ffffffff80cfdcb8 tp : ffffffe000f30000 t0 : ffffffff80d0b0cf
[    0.402602]  t1 : ffffffff80d0b0c0 t2 : 0000000000000000 s0 : ffffffe000f3bd60
[    0.403071]  s1 : ffffffff808bc2e8 a0 : 0000000000001000 a1 : 0000000000000000
[    0.403448]  a2 : ffffffff803d7088 a3 : ffffffff808bc2e8 a4 : 6131725dbc24d400
[    0.403820]  a5 : 0000000000001000 a6 : 0000000000000002 a7 : ffffffffffffffff
[    0.404226]  s2 : 0000000000000000 s3 : 0000000000000000 s4 : 0000000000000000
[    0.404634]  s5 : ffffffff803d7088 s6 : ffffffff808bc2e8 s7 : ffffffff80630650
[    0.405085]  s8 : ffffffff80912a80 s9 : 0000000000000008 s10: ffffffff804000fc
[    0.405388]  s11: 0000000000000000 t3 : 0000000000000043 t4 : ffffffffffffffff
[    0.405616]  t5 : 000000000000003d t6 : ffffffe000f3baa8
[    0.405793] status: 0000000000000100 badaddr: 0000000000000960 cause: 000000000000000d
[    0.406135] [&lt;ffffffff80004922&gt;] walk_stackframe+0xc4/0xdc
[    0.407032] [&lt;ffffffff8000496a&gt;] dump_backtrace+0x30/0x38
[    0.407797] [&lt;ffffffff803d7100&gt;] show_stack+0x40/0x4c
[    0.408234] [&lt;ffffffff803d9e5c&gt;] dump_stack+0x90/0xb6
[    0.409019] [&lt;ffffffff8040423e&gt;] ptdump_init+0x20/0xc4
[    0.409681] [&lt;ffffffff800015b6&gt;] do_one_initcall+0x4c/0x226
[    0.410110] [&lt;ffffffff80401094&gt;] kernel_init_freeable+0x1f4/0x258
[    0.410562] [&lt;ffffffff803dba88&gt;] kernel_init+0x22/0x148
[    0.410959] [&lt;ffffffff800029e2&gt;] ret_from_exception+0x0/0x14
[    0.412241] ---[ end trace b2ab92c901b96251 ]---
[    0.413099] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b

The reason is the task is NULL when we finally call walk_stackframe()
the NULL is passed from __dump_stack():

|static void __dump_stack(void)
|{
|        dump_stack_print_info(KERN_DEFAULT);
|        show_stack(NULL, NULL, KERN_DEFAULT);
|}

Fix this issue by checking "task == NULL" case in walk_stackframe().

Fixes: eac2f3059e02 ("riscv: stacktrace: fix the riscv stacktrace when CONFIG_FRAME_POINTER enabled")
Signed-off-by: Jisheng Zhang &lt;jszhang@kernel.org&gt;
Reviewed-by: Atish Patra &lt;atish.patra@wdc.com&gt;
Tested-by: Wende Tan &lt;twd2.me@gmail.com&gt;
Signed-off-by: Palmer Dabbelt &lt;palmerdabbelt@google.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>riscv: stacktrace: pin the task's stack in get_wchan</title>
<updated>2021-07-24T00:29:03+00:00</updated>
<author>
<name>Jisheng Zhang</name>
<email>jszhang@kernel.org</email>
</author>
<published>2021-07-23T00:22:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=76f5dfacfb42b75e5782c017827877cfcee20474'/>
<id>76f5dfacfb42b75e5782c017827877cfcee20474</id>
<content type='text'>
Pin the task's stack before calling walk_stackframe() in get_wchan().
This can fix the panic as reported by Andreas when CONFIG_VMAP_STACK=y:

[   65.609696] Unable to handle kernel paging request at virtual address ffffffd0003bbde8
[   65.610460] Oops [#1]
[   65.610626] Modules linked in: virtio_blk virtio_mmio rtc_goldfish btrfs blake2b_generic libcrc32c xor raid6_pq sg dm_multipath dm_mod scsi_dh_rdac scsi_dh_emc scsi_dh_alua efivarfs
[   65.611670] CPU: 2 PID: 1 Comm: systemd Not tainted 5.14.0-rc1-1.g34fe32a-default #1 openSUSE Tumbleweed (unreleased) c62f7109153e5a0897ee58ba52393ad99b070fd2
[   65.612334] Hardware name: riscv-virtio,qemu (DT)
[   65.613008] epc : get_wchan+0x5c/0x88
[   65.613334]  ra : get_wchan+0x42/0x88
[   65.613625] epc : ffffffff800048a4 ra : ffffffff8000488a sp : ffffffd00021bb90
[   65.614008]  gp : ffffffff817709f8 tp : ffffffe07fe91b80 t0 : 00000000000001f8
[   65.614411]  t1 : 0000000000020000 t2 : 0000000000000000 s0 : ffffffd00021bbd0
[   65.614818]  s1 : ffffffd0003bbdf0 a0 : 0000000000000001 a1 : 0000000000000002
[   65.615237]  a2 : ffffffff81618008 a3 : 0000000000000000 a4 : 0000000000000000
[   65.615637]  a5 : ffffffd0003bc000 a6 : 0000000000000002 a7 : ffffffe27d370000
[   65.616022]  s2 : ffffffd0003bbd90 s3 : ffffffff8071a81e s4 : 0000000000003fff
[   65.616407]  s5 : ffffffffffffc000 s6 : 0000000000000000 s7 : ffffffff81618008
[   65.616845]  s8 : 0000000000000001 s9 : 0000000180000040 s10: 0000000000000000
[   65.617248]  s11: 000000000000016b t3 : 000000ff00000000 t4 : 0c6aec92de5e3fd7
[   65.617672]  t5 : fff78f60608fcfff t6 : 0000000000000078
[   65.618088] status: 0000000000000120 badaddr: ffffffd0003bbde8 cause: 000000000000000d
[   65.618621] [&lt;ffffffff800048a4&gt;] get_wchan+0x5c/0x88
[   65.619008] [&lt;ffffffff8022da88&gt;] do_task_stat+0x7a2/0xa46
[   65.619325] [&lt;ffffffff8022e87e&gt;] proc_tgid_stat+0xe/0x16
[   65.619637] [&lt;ffffffff80227dd6&gt;] proc_single_show+0x46/0x96
[   65.619979] [&lt;ffffffff801ccb1e&gt;] seq_read_iter+0x190/0x31e
[   65.620341] [&lt;ffffffff801ccd70&gt;] seq_read+0xc4/0x104
[   65.620633] [&lt;ffffffff801a6bfe&gt;] vfs_read+0x6a/0x112
[   65.620922] [&lt;ffffffff801a701c&gt;] ksys_read+0x54/0xbe
[   65.621206] [&lt;ffffffff801a7094&gt;] sys_read+0xe/0x16
[   65.621474] [&lt;ffffffff8000303e&gt;] ret_from_syscall+0x0/0x2
[   65.622169] ---[ end trace f24856ed2b8789c5 ]---
[   65.622832] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b

Signed-off-by: Jisheng Zhang &lt;jszhang@kernel.org&gt;
Signed-off-by: Palmer Dabbelt &lt;palmerdabbelt@google.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pin the task's stack before calling walk_stackframe() in get_wchan().
This can fix the panic as reported by Andreas when CONFIG_VMAP_STACK=y:

[   65.609696] Unable to handle kernel paging request at virtual address ffffffd0003bbde8
[   65.610460] Oops [#1]
[   65.610626] Modules linked in: virtio_blk virtio_mmio rtc_goldfish btrfs blake2b_generic libcrc32c xor raid6_pq sg dm_multipath dm_mod scsi_dh_rdac scsi_dh_emc scsi_dh_alua efivarfs
[   65.611670] CPU: 2 PID: 1 Comm: systemd Not tainted 5.14.0-rc1-1.g34fe32a-default #1 openSUSE Tumbleweed (unreleased) c62f7109153e5a0897ee58ba52393ad99b070fd2
[   65.612334] Hardware name: riscv-virtio,qemu (DT)
[   65.613008] epc : get_wchan+0x5c/0x88
[   65.613334]  ra : get_wchan+0x42/0x88
[   65.613625] epc : ffffffff800048a4 ra : ffffffff8000488a sp : ffffffd00021bb90
[   65.614008]  gp : ffffffff817709f8 tp : ffffffe07fe91b80 t0 : 00000000000001f8
[   65.614411]  t1 : 0000000000020000 t2 : 0000000000000000 s0 : ffffffd00021bbd0
[   65.614818]  s1 : ffffffd0003bbdf0 a0 : 0000000000000001 a1 : 0000000000000002
[   65.615237]  a2 : ffffffff81618008 a3 : 0000000000000000 a4 : 0000000000000000
[   65.615637]  a5 : ffffffd0003bc000 a6 : 0000000000000002 a7 : ffffffe27d370000
[   65.616022]  s2 : ffffffd0003bbd90 s3 : ffffffff8071a81e s4 : 0000000000003fff
[   65.616407]  s5 : ffffffffffffc000 s6 : 0000000000000000 s7 : ffffffff81618008
[   65.616845]  s8 : 0000000000000001 s9 : 0000000180000040 s10: 0000000000000000
[   65.617248]  s11: 000000000000016b t3 : 000000ff00000000 t4 : 0c6aec92de5e3fd7
[   65.617672]  t5 : fff78f60608fcfff t6 : 0000000000000078
[   65.618088] status: 0000000000000120 badaddr: ffffffd0003bbde8 cause: 000000000000000d
[   65.618621] [&lt;ffffffff800048a4&gt;] get_wchan+0x5c/0x88
[   65.619008] [&lt;ffffffff8022da88&gt;] do_task_stat+0x7a2/0xa46
[   65.619325] [&lt;ffffffff8022e87e&gt;] proc_tgid_stat+0xe/0x16
[   65.619637] [&lt;ffffffff80227dd6&gt;] proc_single_show+0x46/0x96
[   65.619979] [&lt;ffffffff801ccb1e&gt;] seq_read_iter+0x190/0x31e
[   65.620341] [&lt;ffffffff801ccd70&gt;] seq_read+0xc4/0x104
[   65.620633] [&lt;ffffffff801a6bfe&gt;] vfs_read+0x6a/0x112
[   65.620922] [&lt;ffffffff801a701c&gt;] ksys_read+0x54/0xbe
[   65.621206] [&lt;ffffffff801a7094&gt;] sys_read+0xe/0x16
[   65.621474] [&lt;ffffffff8000303e&gt;] ret_from_syscall+0x0/0x2
[   65.622169] ---[ end trace f24856ed2b8789c5 ]---
[   65.622832] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b

Signed-off-by: Jisheng Zhang &lt;jszhang@kernel.org&gt;
Signed-off-by: Palmer Dabbelt &lt;palmerdabbelt@google.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
