Re: [PATCH v8 06/12] unwind_user/sframe: Wire up unwind_user to sframe

[Jens Remus <jremus@linux.ibm.com>]

On 08.07.2025 22:11, Steven Rostedt wrote:
> On Tue, 8 Jul 2025 15:58:56 -0400
> Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote:
> 
>>> @@ -111,6 +128,8 @@ static int unwind_user_start(struct unwind_user_state *state)
>>>   
>>>   	if (IS_ENABLED(CONFIG_HAVE_UNWIND_USER_COMPAT_FP) && in_compat_mode(regs))
>>>   		state->type = UNWIND_USER_TYPE_COMPAT_FP;
>>> +	else if (current_has_sframe())
>>> +		state->type = UNWIND_USER_TYPE_SFRAME;  
>>
>> I think you'll want to update the state->type during the
>> traversal (in next()), because depending on whether
>> sframe is available for a given memory area of code
>> or not, the next() function can use either frame pointers
>> or sframe during the same traversal. It would be good
>> to know which is used after each specific call to next().
> 
> From my understanding this sets up what is available for the task at the
> beginning.
> 
> So once we say "this task has sframes" it will try to use it every time. In
> next we have:
> 
> 	if (compat_fp_state(state)) {
> 		frame = &compat_fp_frame;
> 	} else if (sframe_state(state)) {
> 		/* sframe expects the frame to be local storage */
> 		frame = &_frame;
> 		if (sframe_find(state->ip, frame)) {
> 			if (!IS_ENABLED(CONFIG_HAVE_UNWIND_USER_FP))
> 				goto done;
> 			frame = &fp_frame;
> 		}
> 	} else if (fp_state(state)) {
> 		frame = &fp_frame;
> 	} else {
> 		goto done;
> 	}
> 
> Where if sframe_find() fails and we switch over to frame pointers, if frame
> pointers works, we can continue. But the next iteration, where the frame
> pointer finds the previous ip, that ip may be in the sframe section again.
> 
> I've seen this work with my trace_printk()s. A function from code that is
> running sframes calls into a library function that has frame pointers. The
> walk walks through the frame pointers in the library, and when it hits the
> code that has sframes, it starts using that again.

I think Mathieu has a point, as unwind_user_next() calls the optional
architecture-specific arch_unwind_user_next() at the end.  The x86
implementation does state->type specific processing (for
UNWIND_USER_TYPE_COMPAT_FP).

> If we switched the state to just FP, it will never try to use sframes.
> 
> So this state is more about "what does this task have" than what was used
> per iteration.

While there is currently no fallback to UNWIND_USER_TYPE_COMPAT_FP that
would strictly require this, it could be useful to have both information.

Or the logic in unwind_user_start(), unwind_user_next(), and *_state()
may need to be adjusted so that state->type reflects the currently used
method, which unwind_user_next() determines and sets anew for every step.

Regards,
Jens
-- 
Jens Remus
Linux on Z Development (D3303)
+49-7031-16-1128 Office
jremus@de.ibm.com

IBM

IBM Deutschland Research & Development GmbH; Vorsitzender des Aufsichtsrats: Wolfgang Wendt; Geschäftsführung: David Faller; Sitz der Gesellschaft: Böblingen; Registergericht: Amtsgericht Stuttgart, HRB 243294
IBM Data Privacy Statement: https://www.ibm.com/privacy/