summaryrefslogtreecommitdiff
path: root/tools/testing/selftests/bpf/progs/struct_ops_autocreate2.c
diff options
context:
space:
mode:
authorJens Remus <jremus@linux.ibm.com>2025-12-11 12:24:50 +0100
committerHeiko Carstens <hca@linux.ibm.com>2025-12-14 11:03:58 +0100
commit489e96651dfe59794195c6b2ddb78835edd9f2ed (patch)
treef8b7a7c55406b4f6c2c7c05c11dbb3154a7010bd /tools/testing/selftests/bpf/progs/struct_ops_autocreate2.c
parentaf241e6bfc11125e6669dabf0800fce6809dd3cf (diff)
s390/stacktrace: Do not fallback to RA register
The logic to fallback to the return address (RA) register value in the topmost frame when stack tracing using back chain is broken in multiple ways: When assuming the RA register 14 has not been saved yet one must assume that a new user stack frame has not been allocated either. Therefore the back chain would not contain the stack pointer (SP) at entry, but the caller's SP at its entry instead. Therefore when falling back to the RA register 14 value it would also be necessary to fallback to the SP register 15 value. Otherwise an invalid combination of RA register 14 and caller's SP at its entry (from the back chain) is used. In the topmost frame the back chain contains either the caller's SP at its entry (before having allocated a new stack frame in the prologue), the SP at entry (after having allocated a new stack frame), or an uninitialized value (during static/dynamic stack allocation). In both cases where the back chain is valid either the caller or prologue must have saved its respective RA to the respective frame. Therefore, if the RA obtained from the frame pointed to by the back chain is invalid, this does not indicate that the IP in the topmost frame is still early in the prologue and the RA has not been saved. Reviewed-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Jens Remus <jremus@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Diffstat (limited to 'tools/testing/selftests/bpf/progs/struct_ops_autocreate2.c')
0 files changed, 0 insertions, 0 deletions