linux-stable.git/arch/s390/kernel/unwind_bc.c, branch linux-rolling-stable

s390: Explicitly include

2025-06-17T16:18:02+00:00

Explicitly include  in files which contain an
EXPORT_SYMBOL().

See commit a934a57a42f6 ("scripts/misc-check: check missing #include
 when W=1") for more details.

Acked-by: Alexander Gordeev 
Signed-off-by: Heiko Carstens 
Signed-off-by: Alexander Gordeev

s390/unwind: disable KMSAN checks

2024-07-04T02:30:25+00:00

The unwind code can read uninitialized frames.  Furthermore, even in the
good case, KMSAN does not emit shadow for backchains.  Therefore disable
it for the unwinding functions.

Link: https://lkml.kernel.org/r/20240621113706.315500-37-iii@linux.ibm.com
Signed-off-by: Ilya Leoshkevich 
Reviewed-by: Alexander Potapenko 
Acked-by: Heiko Carstens 
Cc: Alexander Gordeev 
Cc: Christian Borntraeger 
Cc: Christoph Lameter 
Cc: David Rientjes 
Cc: Dmitry Vyukov 
Cc: Hyeonggon Yoo <42.hyeyoo@gmail.com>
Cc: Joonsoo Kim 
Cc: 
Cc: Marco Elver 
Cc: Mark Rutland 
Cc: Masami Hiramatsu (Google) 
Cc: Pekka Enberg 
Cc: Roman Gushchin 
Cc: Steven Rostedt (Google) 
Cc: Sven Schnelle 
Cc: Vasily Gorbik 
Cc: Vlastimil Babka 
Signed-off-by: Andrew Morton

s390/unwind: avoid duplicated unwinding entries for kretprobes

2022-03-27T20:18:39+00:00

Currently when unwinding starts from pt_regs or encounters pt_regs along
the way unwinder tries to yield 2 unwinding entries:
1. (reliable)     ip1: pt_regs->psw.addr,  sp1: regs->gprs[15]
2. (non-reliable) ip2: sp1->gprs[8] (r14), sp2: regs->gprs[15]

In case of kretprobes those are identical and serves no other purpose
than causing confusion over duplicated entries and cause kprobes tests
to fail. So, skip a duplicate non-reliable entry in this case.

With that kretprobes and unwinder implementation now comply with
ARCH_CORRECT_STACKTRACE_ON_KRETPROBE.

Reviewed-by: Tobias Huschle 
Signed-off-by: Vasily Gorbik

s390/unwind: recover kretprobe modified return address in stacktrace

2022-03-27T20:18:39+00:00

Based on commit cd9bc2c92588 ("arm64: Recover kretprobe modified return
address in stacktrace").

"""
Since the kretprobe replaces the function return address with
the __kretprobe_trampoline on the stack, stack unwinder shows it
instead of the correct return address.

This checks whether the next return address is the
__kretprobe_trampoline(), and if so, try to find the correct
return address from the kretprobe instance list.
"""

Original patch series:
https://lore.kernel.org/all/163163030719.489837.2236069935502195491.stgit@devnote2/

Reviewed-by: Tobias Huschle 
Signed-off-by: Vasily Gorbik

s390/unwind: stop gracefully at user mode pt_regs in irq stack

2019-12-18T22:29:26+00:00

Consider reaching user mode pt_regs at the bottom of irq stack graceful
unwinder termination. This is the case when irq/mcck/ext interrupt arrives
while in user mode.

Signed-off-by: Vasily Gorbik

s390/unwind: add stack pointer alignment sanity checks

2019-11-30T09:52:48+00:00

ABI requires SP to be aligned 8 bytes, report unwinding error otherwise.

Link: https://lkml.kernel.org/r/20191106095601.29986-5-mbenes@suse.cz
Reviewed-by: Heiko Carstens 
Tested-by: Miroslav Benes 
Signed-off-by: Miroslav Benes 
Signed-off-by: Vasily Gorbik

s390/unwind: filter out unreliable bogus %r14

2019-11-30T09:52:48+00:00

Currently unwinder unconditionally returns %r14 from the first frame
pointed by %r15 from pt_regs. A task could be interrupted when a function
already allocated this frame (if it needs it) for its callees or to
store local variables. In that case this frame would contain random
values from stack or values stored there by a callee. As we are only
interested in %r14 to get potential return address, skip bogus return
addresses which doesn't belong to kernel text.

This helps to avoid duplicating filtering logic in unwider users, most
of which use unwind_get_return_address() and would choke on bogus 0
address returned by it otherwise.

Reviewed-by: Heiko Carstens 
Signed-off-by: Vasily Gorbik

s390/unwind: start unwinding from reliable state

2019-11-30T09:52:48+00:00

A comment in arch/s390/include/asm/unwind.h says:
> If 'first_frame' is not zero unwind_start skips unwind frames until it
> reaches the specified stack pointer.
> The end of the unwinding is indicated with unwind_done, this can be true
> right after unwind_start, e.g. with first_frame!=0 that can not be found.
> unwind_next_frame skips to the next frame.
> Once the unwind is completed unwind_error() can be used to check if there
> has been a situation where the unwinder could not correctly understand
> the tasks call chain.

With this change backchain unwinder now comply with behaviour
described. As well as matches orc unwinder implementation.  Now unwinder
starts from reliable state, i.e. __unwind_start own stack frame is
taken or stack frame generated by __switch_to (ksp) - both known to be
valid. In case of pt_regs %r15 is better match for pt_regs psw, than
sometimes random "sp" caller passed.

Reviewed-by: Heiko Carstens 
Signed-off-by: Vasily Gorbik

s390/unwind: stop gracefully at task pt_regs

2019-11-30T09:52:45+00:00

Consider reaching task pt_regs graceful unwinder termination. Task
pt_regs itself never contains a valid state to which a task might return
within the kernel context (user task pt_regs is a special case). Since
we already avoid printing user task pt_regs and in most cases we don't
even bother filling task pt_regs psw and r15 with something reasonable
simply skip task pt_regs altogether. With this change unwind_error() now
accurately represent whether unwinder reached task pt_regs successfully
or failed along the way.

Reviewed-by: Heiko Carstens 
Signed-off-by: Vasily Gorbik

s390/unwind: make reuse_sp default when unwinding pt_regs

2019-11-30T09:52:45+00:00

Currently unwinder yields 2 entries when pt_regs are met:
sp="address of pt_regs itself" ip=pt_regs->psw
sp=pt_regs->gprs[15] ip="r14 from stack frame pointed by pt_regs->gprs[15]"

And neither of those 2 states (combination of sp and ip) ever happened.

reuse_sp has been introduced by commit a1d863ac3e10 ("s390/unwind: fix
mixing regs and sp"). reuse_sp=true makes unwinder keen to produce the
following result, when pt_regs are given (as an arg to unwind_start):
sp=pt_regs->gprs[15] ip=pt_regs->psw
sp=pt_regs->gprs[15] ip="r14 from stack frame pointed by pt_regs->gprs[15]"

The first state is an actual state in which a task was when pt_regs were
collected. The second state is marked unreliable and is for debugging
purposes to cover the case when a task has been interrupted in between
stack frame allocation and writing back_chain - in this case r14 might
show an actual caller.

Make unwinder behaviour enabled via reuse_sp=true default and drop the
special case handling.

Reviewed-by: Heiko Carstens 
Signed-off-by: Vasily Gorbik