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 <[email protected]> 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. > 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 [ ... ] > @@ -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/[email protected]?part=11
