Re: [RFC PATCH v1 11/25] unwind_user/eh_frame: Wire up unwind_user to eh_frame

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