diff options
| author | Jens Remus <jremus@linux.ibm.com> | 2025-12-11 12:24:50 +0100 |
|---|---|---|
| committer | Heiko Carstens <hca@linux.ibm.com> | 2025-12-14 11:03:58 +0100 |
| commit | 489e96651dfe59794195c6b2ddb78835edd9f2ed (patch) | |
| tree | f8b7a7c55406b4f6c2c7c05c11dbb3154a7010bd /tools/testing/selftests/kvm/lib/userfaultfd_util.c | |
| parent | af241e6bfc11125e6669dabf0800fce6809dd3cf (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/kvm/lib/userfaultfd_util.c')
0 files changed, 0 insertions, 0 deletions
