summaryrefslogtreecommitdiff
path: root/scripts/stackusage
diff options
context:
space:
mode:
authorZheng Yejian <zhengyejian@huaweicloud.com>2024-09-13 10:45:01 +0800
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2024-12-05 14:01:21 +0100
commit13ac2e6e6d884cf44d2b9742872f7e4658d79b94 (patch)
tree6580c5b301a435fe96feae12eb247bf1d8fddd39 /scripts/stackusage
parentad3dad3f152e9225572c13955d1ae249f46d7d06 (diff)
downloadlinux-13ac2e6e6d884cf44d2b9742872f7e4658d79b94.tar.gz
linux-13ac2e6e6d884cf44d2b9742872f7e4658d79b94.tar.bz2
linux-13ac2e6e6d884cf44d2b9742872f7e4658d79b94.zip
x86/unwind/orc: Fix unwind for newly forked tasks
[ Upstream commit 3bf19a0fb690022ec22ce87a5afeb1030cbcb56c ] When arch_stack_walk_reliable() is called to unwind for newly forked tasks, the return value is negative which means the call stack is unreliable. This obviously does not meet expectations. The root cause is that after commit 3aec4ecb3d1f ("x86: Rewrite ret_from_fork() in C"), the 'ret_addr' of newly forked task is changed to 'ret_from_fork_asm' (see copy_thread()), then at the start of the unwind, it is incorrectly interprets not as a "signal" one because 'ret_from_fork' is still used to determine the initial "signal" (see __unwind_start()). Then the address gets incorrectly decremented in the call to orc_find() (see unwind_next_frame()) and resulting in the incorrect ORC data. To fix it, check 'ret_from_fork_asm' rather than 'ret_from_fork' in __unwind_start(). Fixes: 3aec4ecb3d1f ("x86: Rewrite ret_from_fork() in C") Signed-off-by: Zheng Yejian <zhengyejian@huaweicloud.com> Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
Diffstat (limited to 'scripts/stackusage')
0 files changed, 0 insertions, 0 deletions