Re: [RFC PATCH v2 21/24] unwind_user/eh_frame/x86: Handle DRAP expressions

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The newly added DRAP DWARF expression handling for the Frame Pointer (FP) uses a generic register rule that unconditionally fails for non-topmost frames, causing premature stack trace truncation.
--

--- Patch [21]: [RFC PATCH v2 21/24] unwind_user/eh_frame/x86: Handle DRAP expressions ---
commit a27cd1aa620d26189650492016f14beeb35a7207
Author: Jens Remus <[email protected]>

unwind_user/eh_frame/x86: Handle DRAP expressions

This commit adds x86-specific handling for DRAP CFA and FP expressions.
It supports unwinding through frames with dynamically realigned stacks by
parsing the corresponding DWARF expressions.

> diff --git a/kernel/unwind/eh_frame.c b/kernel/unwind/eh_frame.c
> --- a/kernel/unwind/eh_frame.c
> +++ b/kernel/unwind/eh_frame.c

[ ... ]

> @@ -1184,6 +1209,16 @@ static __always_inline int __find_frame_row(struct eh_frame_section *sec,
>  		frame->fp.regnum = ctx.state.reg_regnum[FP_IDX];
>  		frame->fp.offset = 0;
>  		break;
> +	case REG_REGISTER_OFFSET_DEREF:
> +		if (ctx.state.reg_regnum[FP_IDX] > UINT_MAX)
> +			return -EINVAL;
> +		if (ctx.state.reg_offset[FP_IDX] < INT_MIN ||
> +		    ctx.state.reg_offset[FP_IDX] > INT_MAX)
> +			return -EOPNOTSUPP;
> +		frame->fp.rule = UNWIND_USER_RULE_REG_OFFSET_DEREF;
> +		frame->fp.regnum = ctx.state.reg_regnum[FP_IDX];
> +		frame->fp.offset = ctx.state.reg_offset[FP_IDX];
> +		break;

[Severity: Medium]
Will this generic register rule cause stack trace truncation for non-topmost
frames?

Looking at unwind_user_next_common(), UNWIND_USER_RULE_REG_OFFSET_DEREF is
unconditionally rejected unless it's the topmost frame:

kernel/unwind/user.c:unwind_user_next_common() {
    ...
    case UNWIND_USER_RULE_REG_OFFSET_DEREF:
        if (!state->topmost || unwind_user_get_reg(&fp, frame->fp.regnum))
            return -EINVAL;
    ...
}

Because EH_FRAME_REG_FP is tracked across frames, could this use a dedicated
FP rule to avoid aborting the stack trace when encountering a DRAP frame that
isn't the innermost frame?

>  	default:
>  		return -EINVAL;
>  	}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=21