diff options
| author | Eric Biggers <ebiggers@kernel.org> | 2026-10-11 15:48:43 +0200 |
|---|---|---|
| committer | Eric Biggers <ebiggers@kernel.org> | 2026-10-13 15:41:39 +0200 |
| commit | 40f47fa10a1d19c74f48a13d97b2eb19d5fb938d (patch) | |
| tree | a124c6e7deedf72160b0f8db474e7f0922c3878c /tools/perf/scripts/python/bin/stackcollapse-report | |
| parent | cc76c9b82bf5272ce9bcc17df8c2aa21b6dfef0f (diff) | |
| download | linux-40f47fa10a1d19c74f48a13d97b2eb19d5fb938d.tar.gz linux-40f47fa10a1d19c74f48a13d97b2eb19d5fb938d.zip | |
lib/crypto: x86/sha512: Follow the normal %rbp convention
The SHA-512 assembly functions push callee-save GPRs to the stack
*before* they set up the frame pointer (%rbp). (They are leaf
functions, but they need to set up a frame pointer anyway because they
allocate a 32-byte-aligned buffer on the stack.)
As a result, during these functions, 8(%rbp) doesn't contain a return
address like it is supposed to.
This differs from the convention used by C code, and it interferes with
the frame pointer unwinder (CONFIG_UNWINDER_FRAME_POINTER=y).
Specifically, if a call trace is dumped in these functions, then all
entries are populated purely from the fallback scan of the entire stack:
RIP: 0010:sha512_transform_rorx+0x673/0xdf0
[...]
Call Trace:
<TASK>
? sha512_blocks_avx2+0x37/0x60
? __sha512_update+0x80/0x230
? sha512+0x31/0x190
? sha512+0x114/0x190
[...]
? do_syscall_64+0x6f/0x3e0
With this fix to follow the normal %rbp convention, the call trace is
generated reliably:
RIP: 0010:sha512_transform_rorx+0x90c/0xdf0
[...]
Call Trace:
<TASK>
sha512_blocks_avx2+0x37/0x60
__sha512_update+0x80/0x230
sha512+0x114/0x190
[...]
do_syscall_64+0x6f/0x3e0
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://patch.msgid.link/20261011134843.166585-4-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
Diffstat (limited to 'tools/perf/scripts/python/bin/stackcollapse-report')
0 files changed, 0 insertions, 0 deletions
