linux.git/arch/riscv/kernel/stacktrace.c, branch v5.10.258

riscv: Use READ_ONCE_NOCHECK in imprecise unwinding stack mode

2023-03-17T07:45:12+00:00

[ Upstream commit 76950340cf03b149412fe0d5f0810e52ac1df8cb ]

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] [] walk_stackframe+0x0/0x11a
[    0.000000] [] init_param_lock+0x26/0x2a
[    0.000000] [] walk_stackframe+0xa2/0x11a
[    0.000000] [] dump_stack_lvl+0x22/0x36
[    0.000000] [] print_report+0x198/0x4a8
[    0.000000] [] init_param_lock+0x26/0x2a
[    0.000000] [] walk_stackframe+0xa2/0x11a
[    0.000000] [] kasan_report+0x9a/0xc8
[    0.000000] [] walk_stackframe+0xa2/0x11a
[    0.000000] [] walk_stackframe+0xa2/0x11a
[    0.000000] [] desc_make_final+0x80/0x84
[    0.000000] [] stack_trace_save+0x88/0xa6
[    0.000000] [] filter_irq_stacks+0x72/0x76
[    0.000000] [] devkmsg_read+0x32a/0x32e
[    0.000000] [] kasan_save_stack+0x28/0x52
[    0.000000] [] desc_make_final+0x7c/0x84
[    0.000000] [] stack_trace_save+0x84/0xa6
[    0.000000] [] kasan_set_track+0x12/0x20
[    0.000000] [] __kasan_slab_alloc+0x58/0x5e
[    0.000000] [] __kmem_cache_create+0x21e/0x39a
[    0.000000] [] create_boot_cache+0x70/0x9c
[    0.000000] [] kmem_cache_init+0x6c/0x11e
[    0.000000] [] mm_init+0xd8/0xfe
[    0.000000] [] 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] >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 
Link: https://lore.kernel.org/all/CAD7mqryDQCYyJ1gAmtMm8SASMWAQ4i103ptTb0f6Oda=tPY2=A@mail.gmail.com/
Suggested-by: Dmitry Vyukov 
Signed-off-by: Alexandre Ghiti 
Link: https://lore.kernel.org/r/20230308091639.602024-1-alexghiti@rivosinc.com
Signed-off-by: Palmer Dabbelt 
Signed-off-by: Sasha Levin

riscv: stacktrace: Fixup ftrace_graph_ret_addr retp argument

2023-01-14T09:16:42+00:00

[ Upstream commit 5c3022e4a616d800cf5f4c3a981d7992179e44a1 ]

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 
Signed-off-by: Guo Ren 
Link: https://lore.kernel.org/r/20221109064937.3643993-2-guoren@kernel.org
Cc: stable@vger.kernel.org
Signed-off-by: Palmer Dabbelt 
Signed-off-by: Sasha Levin

riscv/stacktrace: Fix stack output without ra on the stack top

2023-01-14T09:16:42+00:00

[ Upstream commit f766f77a74f5784d8d4d3c36b1900731f97d08d0 ]

When a function doesn't have a callee, then it will not
push ra into the stack, such as lkdtm_BUG() function,

addi	sp,sp,-16
sd	s0,8(sp)
addi	s0,sp,16
ebreak

The struct stackframe use {fp,ra} to get information from
stack, if walk_stackframe() with pr_regs, we will obtain
wrong value and bad stacktrace,

[] lkdtm_BUG+0x6/0x8
---[ end trace 18da3fbdf08e25d5 ]---

Correct the next fp and pc, after that, full stacktrace
shown as expects,

[] lkdtm_BUG+0x6/0x8
[] lkdtm_do_action+0x14/0x1c
[] direct_entry+0xc0/0x10a
[] full_proxy_write+0x42/0x6a
[] vfs_write+0x7e/0x214
[] ksys_write+0x98/0xc0
[] sys_write+0xe/0x16
[] ret_from_syscall+0x0/0x2
---[ end trace 61917f3d9a9fadcd ]---

Signed-off-by: Chen Huang 
Signed-off-by: Kefeng Wang 
Signed-off-by: Palmer Dabbelt 
Stable-dep-of: 5c3022e4a616 ("riscv: stacktrace: Fixup ftrace_graph_ret_addr retp argument")
Signed-off-by: Sasha Levin

kernel: rename show_stack_loglvl() => show_stack()

2020-06-09T16:39:13+00:00

Now the last users of show_stack() got converted to use an explicit log
level, show_stack_loglvl() can drop it's redundant suffix and become once
again well known show_stack().

Signed-off-by: Dmitry Safonov 
Signed-off-by: Andrew Morton 
Link: http://lkml.kernel.org/r/20200418201944.482088-51-dima@arista.com
Signed-off-by: Linus Torvalds

riscv: add show_stack_loglvl()

2020-06-09T16:39:11+00:00

Currently, the log-level of show_stack() depends on a platform
realization.  It creates situations where the headers are printed with
lower log level or higher than the stacktrace (depending on a platform or
user).

Furthermore, it forces the logic decision from user to an architecture
side.  In result, some users as sysrq/kdb/etc are doing tricks with
temporary rising console_loglevel while printing their messages.  And in
result it not only may print unwanted messages from other CPUs, but also
omit printing at all in the unlucky case where the printk() was deferred.

Introducing log-level parameter and KERN_UNSUPPRESSED [1] seems an easier
approach than introducing more printk buffers.  Also, it will consolidate
printings with headers.

Introduce show_stack_loglvl(), that eventually will substitute
show_stack().

[1]: https://lore.kernel.org/lkml/20190528002412.1625-1-dima@arista.com/T/#u

Signed-off-by: Dmitry Safonov 
Signed-off-by: Andrew Morton 
Cc: Albert Ou 
Cc: Palmer Dabbelt 
Cc: Paul Walmsley 
Link: http://lkml.kernel.org/r/20200418201944.482088-28-dima@arista.com
Signed-off-by: Linus Torvalds

kallsyms/printk: add loglvl to print_ip_sym()

2020-06-09T16:39:10+00:00

Patch series "Add log level to show_stack()", v3.

Add log level argument to show_stack().

Done in three stages:
1. Introducing show_stack_loglvl() for every architecture
2. Migrating old users with an explicit log level
3. Renaming show_stack_loglvl() into show_stack()

Justification:

- It's a design mistake to move a business-logic decision into platform
  realization detail.

- I have currently two patches sets that would benefit from this work:
  Removing console_loglevel jumps in sysrq driver [1] Hung task warning
  before panic [2] - suggested by Tetsuo (but he probably didn't realise
  what it would involve).

- While doing (1), (2) the backtraces were adjusted to headers and other
  messages for each situation - so there won't be a situation when the
  backtrace is printed, but the headers are missing because they have
  lesser log level (or the reverse).

- As the result in (2) plays with console_loglevel for kdb are removed.

The least important for upstream, but maybe still worth to note that every
company I've worked in so far had an off-list patch to print backtrace
with the needed log level (but only for the architecture they cared
about).  If you have other ideas how you will benefit from show_stack()
with a log level - please, reply to this cover letter.

See also discussion on v1:
https://lore.kernel.org/linux-riscv/20191106083538.z5nlpuf64cigxigh@pathway.suse.cz/

This patch (of 50):

print_ip_sym() needs to have a log level parameter to comply with other
parts being printed.  Otherwise, half of the expected backtrace would be
printed and other may be missing with some logging level.

The following callee(s) are using now the adjusted log level:
- microblaze/unwind: the same level as headers & userspace unwind.
  Note that pr_debug()'s there are for debugging the unwinder itself.
- nds32/traps: symbol addresses are printed with the same log level
  as backtrace headers.
- lockdep: ip for locking issues is printed with the same log level
  as other part of the warning.
- sched: ip where preemption was disabled is printed as error like
  the rest part of the message.
- ftrace: bug reports are now consistent in the log level being used.

Signed-off-by: Dmitry Safonov 
Signed-off-by: Andrew Morton 
Acked-by: Steven Rostedt (VMware) 
Cc: Albert Ou 
Cc: Ben Segall 
Cc: Dietmar Eggemann 
Cc: Greentime Hu 
Cc: Greg Kroah-Hartman 
Cc: Ingo Molnar 
Cc: James Hogan 
Cc: Juri Lelli 
Cc: Mel Gorman 
Cc: Michal Simek 
Cc: Palmer Dabbelt 
Cc: Paul Burton 
Cc: Paul Walmsley 
Cc: Peter Zijlstra 
Cc: Ralf Baechle 
Cc: Thomas Gleixner 
Cc: Vincent Chen 
Cc: Vincent Guittot 
Cc: Will Deacon 
Cc: Dmitry Safonov <0x7f454c46@gmail.com>
Cc: Dmitry Safonov 
Cc: Jiri Slaby 
Cc: Petr Mladek 
Cc: Sergey Senozhatsky 
Cc: Ivan Kokshaysky 
Cc: Matt Turner 
Cc: Richard Henderson 
Cc: Vineet Gupta 
Cc: Russell King 
Cc: Catalin Marinas 
Cc: Aurelien Jacquiot 
Cc: Mark Salter 
Cc: Guo Ren 
Cc: Yoshinori Sato 
Cc: Brian Cain 
Cc: Fenghua Yu 
Cc: Tony Luck 
Cc: Geert Uytterhoeven 
Cc: Ley Foon Tan 
Cc: Jonas Bonn 
Cc: Stafford Horne 
Cc: Stefan Kristiansson 
Cc: Helge Deller 
Cc: "James E.J. Bottomley" 
Cc: Benjamin Herrenschmidt 
Cc: Michael Ellerman 
Cc: Paul Mackerras 
Cc: Christian Borntraeger 
Cc: Heiko Carstens 
Cc: Vasily Gorbik 
Cc: Rich Felker 
Cc: "David S. Miller" 
Cc: Anton Ivanov 
Cc: Jeff Dike 
Cc: Richard Weinberger 
Cc: Guan Xuetao 
Cc: Borislav Petkov 
Cc: "H. Peter Anvin" 
Cc: Chris Zankel 
Cc: Max Filippov 
Cc: Len Brown 
Cc: Pavel Machek 
Cc: "Rafael J. Wysocki" 
Cc: "Rafael J. Wysocki" 
Cc: Daniel Thompson 
Cc: Douglas Anderson 
Cc: Jason Wessel 
Link: http://lkml.kernel.org/r/20200418201944.482088-2-dima@arista.com
Signed-off-by: Linus Torvalds

riscv: stacktrace: Fix undefined reference to `walk_stackframe'

2020-05-13T00:04:25+00:00

Drop static declaration to fix following build error if FRAME_POINTER disabled,
  riscv64-linux-ld: arch/riscv/kernel/perf_callchain.o: in function `.L0':
  perf_callchain.c:(.text+0x2b8): undefined reference to `walk_stackframe'

Reported-by: Hulk Robot 
Signed-off-by: Kefeng Wang 
Signed-off-by: Palmer Dabbelt

RISC-V: stacktrace: Declare sp_in_global outside ifdef

2020-04-21T17:50:45+00:00

riscv:allnoconfig and riscv:tinyconfig fail to compile.

arch/riscv/kernel/stacktrace.c: In function 'walk_stackframe':
arch/riscv/kernel/stacktrace.c:78:8: error: 'sp_in_global' undeclared

sp_in_global is declared inside CONFIG_FRAME_POINTER but used outside
of it.

Fixes: 52e7c52d2ded ("RISC-V: Stop relying on GCC's register allocator's hueristics")
Signed-off-by: Guenter Roeck 
Reviewed-by: Palmer Dabbelt 
Signed-off-by: Palmer Dabbelt

RISC-V: Stop relying on GCC's register allocator's hueristics

2020-03-03T18:28:13+00:00

GCC allows users to hint to the register allocation that a variable should be
placed in a register by using a syntax along the lines of

    function(...) {
        register long in_REG __asm__("REG");
    }

We've abused this a bit throughout the RISC-V port to access fixed registers
directly as C variables.  In practice it's never going to blow up because GCC
isn't going to allocate these registers, but it's not a well defined syntax so
we really shouldn't be relying upon this.  Luckily there is a very similar but
well defined syntax that allows us to still access these registers directly as
C variables, which is to simply declare the register variables globally.  For
fixed variables this doesn't change the ABI.

LLVM disallows this ambiguous syntax, so this isn't just strictly a formatting
change.

Signed-off-by: Palmer Dabbelt

riscv: Add perf callchain support

2019-09-04T19:43:00+00:00

This patch add support for perf callchain sampling on riscv platforms.
The return address of leaf function is retrieved from pt_regs as
it is not saved in the outmost frame.

Signed-off-by: Mao Han 
Cc: Paul Walmsley 
Cc: Greentime Hu 
Cc: Palmer Dabbelt 
Cc: linux-riscv 
Cc: Christoph Hellwig 
Cc: Guo Ren 
Tested-by: Greentime Hu 
[paul.walmsley@sifive.com: fixed some 'checkpatch.pl --strict' issues;
 fixed patch description spelling]
Signed-off-by: Paul Walmsley