Re: [RFC PATCH v2 11/24] unwind_user/eh_frame: Wire up unwind_user to eh_frame

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Unadjusted instruction pointer passed to eh_frame_find() for return addresses.
--

--- Patch [11]: [RFC PATCH v2 11/24] unwind_user/eh_frame: Wire up unwind_user to eh_frame ---
commit 242304f470b193c92dc61308cce6cc9e66841ecf
Author: Jens Remus <jremus@linux.ibm.com>

unwind_user/eh_frame: Wire up unwind_user to eh_frame

This commit hooks up the eh_frame infrastructure to the unwind_user
interface. It enables the unwinder to use eh_frame data for user space
stack traces.

> 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: Medium]
Does this need to adjust state->ip for return addresses?

Since state->ip points to the instruction after the call, if a function
call is the final instruction of a block or function, passing the
unadjusted ip to eh_frame_find() might cause it to match the next
function's FDE instead of the caller's.

Would it be better to pass an adjusted instruction pointer (like
state->topmost ? state->ip : state->ip - 1) to ensure the correct unwind
rules are retrieved during normal user space unwinding?

> +		return -ENOENT;
> +	return unwind_user_next_common(state, &frame);
> +}
> +
[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260821195259.2688377-1-jremus@linux.ibm.com?part=11