linux.git/arch/s390/include/asm/stacktrace.h, branch v5.14

s390: rename CALL_ON_STACK_NORETURN() to call_on_stack_noreturn()

2021-07-08T20:12:18+00:00

Lower case matches the call_on_stack() macro and is easier to read.

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

s390: add type checking to CALL_ON_STACK_NORETURN() macro

2021-07-08T20:12:18+00:00

Make sure the to be called function takes no arguments (and returns void).
Otherwise usage of CALL_ON_STACK_NORETURN() would generate broken code.

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

s390: remove old CALL_ON_STACK() macro

2021-07-08T20:12:18+00:00

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

s390: introduce proper type handling call_on_stack() macro

2021-07-08T20:12:17+00:00

The existing CALL_ON_STACK() macro allows for subtle bugs:

- There is no type checking of the function that is being called. That
  is: missing or too many arguments do not cause any compile error or
  warning. The same is true if the return type of the called function
  changes. This can lead to quite random bugs.

- Sign and zero extension of arguments is missing. Given that the s390
  C ABI requires that the caller of a function performs proper sign
  and zero extension this can also lead to subtle bugs.

- If arguments to the CALL_ON_STACK() macros contain functions calls
  register corruption can happen due to register asm constructs being
  used.

Therefore introduce a new call_on_stack() macro which is supposed to
fix all these problems.

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

s390/stack: fix possible register corruption with stack switch helper

2021-06-21T09:19:18+00:00

The CALL_ON_STACK macro is used to call a C function from inline
assembly, and therefore must consider the C ABI, which says that only
registers 6-13, and 15 are non-volatile (restored by the called
function).

The inline assembly incorrectly marks all registers used to pass
parameters to the called function as read-only input operands, instead
of operands that are read and written to. This might result in
register corruption depending on usage, compiler, and compile options.

Fix this by marking all operands used to pass parameters as read/write
operands. To keep the code simple even register 6, if used, is marked
as read-write operand.

Fixes: ff340d2472ec ("s390: add stack switch helper")
Cc:  # 4.20
Reviewed-by: Vasily Gorbik 
Signed-off-by: Heiko Carstens 
Signed-off-by: Vasily Gorbik

s390/unwind: add machine check handler stack

2021-04-05T09:30:07+00:00

Fixes: b61b1595124a ("s390: add stack for machine check handler")
Signed-off-by: Vasily Gorbik 
Signed-off-by: Heiko Carstens

s390: fix register clobbering in CALL_ON_STACK

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

CALL_ON_STACK defines and initializes register variables. Inline
assembly which follows might trigger compiler to generate memory access
for "stack" argument (e.g. in case of S390_lowcore.nodat_stack). This
memory access produces a function call under kasan with outline
instrumentation which clobbers registers.

Switch "stack" argument in CALL_ON_STACK helper to use memory reference
constraint and perform load instead.

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

s390/unwind: always inline get_stack_pointer

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

Always inline get_stack_pointer() to avoid potential problems
due to compiler inlining decisions, i.e. getting stack pointer of
get_stack_pointer() itself which is later reused.

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

s390: avoid misusing CALL_ON_STACK for task stack setup

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

CALL_ON_STACK is intended to be used for temporary stack switching with
potential return to the caller.

When CALL_ON_STACK is misused to switch from nodat stack to task stack
back_chain information would later lead stack unwinder from task stack into
(per cpu) nodat stack which is reused for other purposes. This would
yield confusing unwinding result or errors.

To avoid that introduce CALL_ON_STACK_NORETURN to be used instead. It
makes sure that back_chain is zeroed and unwinder finishes gracefully
ending up at task pt_regs.

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

s390: correct CALL_ON_STACK back_chain saving

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

Currently CALL_ON_STACK saves r15 as back_chain in the first stack frame of
the stack we about to switch to. But if a function which uses CALL_ON_STACK
calls other function it allocates a stack frame for a callee. In this
case r15 is pointing to a callee stack frame and not a stack frame of
function itself. This results in dummy unwinding entry with random
sp and ip values.

Introduce and utilize current_frame_address macro to get an address of
actual function stack frame.

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