linux-toradex.git/arch/s390/kernel/ftrace.c, branch v6.7

s390/ftrace: do not assume module_alloc() returns executable memory

2023-04-13T15:36:26+00:00

The ftrace code assumes at two places that module_alloc() returns
executable memory. While this is currently true, this will be changed
with a subsequent patch to follow other architectures which implement
ARCH_HAS_STRICT_MODULE_RWX.

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

s390/ftrace: move hotpatch trampolines to mcount.S

2023-03-20T10:12:46+00:00

Move the ftrace hotpatch trampolines to mcount.S. This allows to make
use of the standard SYM_CODE macros which again makes sure that the
hotpatch trampolines follow the function alignment rules of the rest
of the kernel.

Signed-off-by: Heiko Carstens 
Acked-by: Ilya Leoshkevich 
Signed-off-by: Heiko Carstens

ftrace: Remove return value of ftrace_arch_modify_*()

2022-05-27T01:13:00+00:00

All instances of the function ftrace_arch_modify_prepare() and
  ftrace_arch_modify_post_process() return zero. There's no point in
  checking their return value. Just have them be void functions.

Link: https://lkml.kernel.org/r/20220518023639.4065-1-kunyu@nfschina.com

Signed-off-by: Li kunyu 
Signed-off-by: Steven Rostedt (Google)

s390: convert ".insn" encoding to instruction names

2022-03-10T14:58:17+00:00

With z10 as minimum supported machine generation many ".insn" encodings
could be now converted to instruction names. There are couple of exceptions
- stfle is used from the als code built for z900 and cannot be converted
- few ".insn" directives encode unsupported instruction formats

The generated code is identical before/after this change.

Acked-by: Ilya Leoshkevich 
Reviewed-by: Heiko Carstens 
Signed-off-by: Vasily Gorbik

s390: raise minimum supported machine generation to z10

2022-03-10T14:58:17+00:00

Machine generations up to z9 (released in May 2006) have been officially
out of service for several years now (z9 end of service - January 31, 2019).
No distributions build kernels supporting those old machine generations
anymore, except Debian, which seems to pick the oldest supported
generation. The team supporting Debian on s390 has been notified about
the change.

Raising minimum supported machine generation to z10 helps to reduce
maintenance cost and effectively remove code, which is not getting
enough testing coverage due to lack of older hardware and distributions
support. Besides that this unblocks some optimization opportunities and
allows to use wider instruction set in asm files for future features
implementation. Due to this change spectre mitigation and usercopy
implementations could be drastically simplified and many newer instructions
could be converted from ".insn" encoding to instruction names.

Acked-by: Ilya Leoshkevich 
Reviewed-by: Heiko Carstens 
Signed-off-by: Vasily Gorbik

Merge branch 'fixes' into features

2022-03-01T20:02:48+00:00

This helps to avoid several merge conflicts later.

* fixes:
  s390/extable: fix exception table sorting
  s390/ftrace: fix arch_ftrace_get_regs implementation
  s390/ftrace: fix ftrace_caller/ftrace_regs_caller generation
  s390/setup: preserve memory at OLDMEM_BASE and OLDMEM_SIZE
  s390/cio: verify the driver availability for path_event call
  s390/module: fix building test_modules_helpers.o with clang
  MAINTAINERS: downgrade myself to Reviewer for s390
  MAINTAINERS: add Alexander Gordeev as maintainer for s390

Signed-off-by: Vasily Gorbik

s390/ftrace: fix arch_ftrace_get_regs implementation

2022-03-01T19:41:28+00:00

arch_ftrace_get_regs is supposed to return a struct pt_regs pointer
only if the pt_regs structure contains all register contents, which
means it must have been populated when created via ftrace_regs_caller.

If it was populated via ftrace_caller the contents are not complete
(the psw mask part is missing), and therefore a NULL pointer needs be
returned.

The current code incorrectly always returns a struct pt_regs pointer.

Fix this by adding another pt_regs flag which indicates if the
contents are complete, and fix arch_ftrace_get_regs accordingly.

Fixes: 894979689d3a ("s390/ftrace: provide separate ftrace_caller/ftrace_regs_caller implementations")
Reported-by: Christophe Leroy 
Reported-by: Naveen N. Rao 
Reviewed-by: Sven Schnelle 
Acked-by: Ilya Leoshkevich 
Signed-off-by: Heiko Carstens 
Signed-off-by: Vasily Gorbik

s390/ftrace: fix ftrace_caller/ftrace_regs_caller generation

2022-03-01T19:41:28+00:00

ftrace_caller was used for both ftrace_caller and ftrace_regs_caller,
which means that the target address of the hotpatch trampoline was
never updated.

With commit 894979689d3a ("s390/ftrace: provide separate
ftrace_caller/ftrace_regs_caller implementations") a separate
ftrace_regs_caller entry point was implemeted, however it was
forgotten to implement the necessary changes for ftrace_modify_call
and ftrace_make_call, where the branch target has to be modified
accordingly.

Therefore add the missing code now.

Fixes: 894979689d3a ("s390/ftrace: provide separate ftrace_caller/ftrace_regs_caller implementations")
Reviewed-by: Sven Schnelle 
Acked-by: Ilya Leoshkevich 
Signed-off-by: Heiko Carstens 
Signed-off-by: Vasily Gorbik

s390/ftrace: verify opcode before applying patch

2022-02-06T22:31:29+00:00

commit 72b3942a173c ("scripts: ftrace - move the
sort-processing in ftrace_init") had the unexpected
side effect that wrong code locations were patched.
To prevent this from happening again, verify the
opcode before patching it.

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

s390: remove invalid email address of Heiko Carstens

2022-02-06T22:31:29+00:00

Remove my old invalid email address which can be found in a couple of
files. Instead of updating it, just remove my contact data completely
from source files.
We have git and other tools which allow to figure out who is responsible
for what with recent contact data.

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