Re: [RFC PATCH v1 11/25] unwind_user/eh_frame: Wire up unwind_user to eh_frame
From: sashiko-bot@kernel.org
Date: 2026-08-18 15:09:56
Also in:
linux-s390
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider: - [High] The unwinder fails to adjust the return address before looking up the FDE for non-topmost frames, leading to unwinding failures or incorrect CFI state at function boundaries. - [High] Child processes created via fork() do not inherit the .eh_frame tracking structures, silently breaking user stack unwinding for all child processes. --
--- Patch [11]: [RFC PATCH v1 11/25] unwind_user/eh_frame: Wire up unwind_user to eh_frame ---commit 409d12d48faaa34ee17f2272fc9cad1cbf48d5d0 Author: Jens Remus [off-list ref] unwind_user/eh_frame: Wire up unwind_user to eh_frame Now that the eh_frame infrastructure is fully in place, make it work by hooking it up to the unwind_user interface. Based on Josh Poimboeuf's, Steven Rostedt's, and my unwind user sframe implementation.
quoted hunk ↗ jump to hunk
diff --git a/kernel/unwind/user.c b/kernel/unwind/user.c index 830c620fe453c..85fc82252af15 100644 --- a/kernel/unwind/user.c +++ b/kernel/unwind/user.c
[ ... ]
quoted hunk ↗ jump to hunk
@@ -173,6 +174,16 @@ static int unwind_user_next_fp(struct unwind_user_state *state) return unwind_user_next_common(state, &fp_frame); } +static int unwind_user_next_eh_frame(struct unwind_user_state *state) +{ + struct unwind_user_frame frame; + + /* eh_frame expects the frame to be local storage */ + if (eh_frame_find(state->ip, &frame))
[Severity: High] Does the lookup need to adjust the instruction pointer for non-topmost frames? When state->ip holds the return address (for non-topmost frames), it points to the instruction after the call. If a function call is the last instruction of an FDE block, passing the unmodified state->ip could cause the lookup to fall outside the FDE or into the next function's FDE. Could this lead to incorrect unwinding state or unwinding failures at function boundaries?
+ return -ENOENT; + return unwind_user_next_common(state, &frame); +}
[Severity: High] Are the .eh_frame tracking structures properly inherited by child processes? When a process is duplicated in dup_mmap() in kernel/fork.c, it seems the parent's mm->eh_frame_mt maple tree is not duplicated. The child's tree is initialized as completely empty in mm_init_eh_frame(). Will this silently break user stack unwinding for any child process created via fork(), since unwinding attempts will search an empty tree and return -ENOENT? -- Sashiko AI review · https://sashiko.dev/#/patchset/20260818144954.2320378-1-jremus@linux.ibm.com?part=11