bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jens Remus <jremus@linux.ibm.com>
To: linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
	linux-s390@vger.kernel.org, bpf@vger.kernel.org, x86@kernel.org,
	Steven Rostedt <rostedt@kernel.org>
Cc: Heiko Carstens <hca@linux.ibm.com>,
	Vasily Gorbik <gor@linux.ibm.com>,
	Ilya Leoshkevich <iii@linux.ibm.com>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@kernel.org>, Jiri Olsa <jolsa@kernel.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Andrii Nakryiko <andrii@kernel.org>,
	Indu Bhagat <indu.bhagat@oracle.com>,
	"Jose E. Marchesi" <jemarch@gnu.org>,
	Beau Belgrave <beaub@linux.microsoft.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Florian Weimer <fweimer@redhat.com>, Kees Cook <kees@kernel.org>,
	"Carlos O'Donell" <codonell@redhat.com>,
	Sam James <sam@gentoo.org>, Dylan Hatch <dylanbhatch@google.com>
Subject: Re: [RFC PATCH v3 17/17] s390/unwind_user/fp: Enable back chain unwinding of user space
Date: Fri, 12 Dec 2025 10:21:38 +0100	[thread overview]
Message-ID: <e38c0be1-52af-49a0-8bbc-1148ad3cc32e@linux.ibm.com> (raw)
In-Reply-To: <20251208171559.2029709-18-jremus@linux.ibm.com>

On 12/8/2025 6:15 PM, Jens Remus wrote:

...

> Leverage the unwind user fp infrastructure to enable unwinding of user
> space using back chain.  Enable HAVE_UNWIND_USER_FP and provide a s390-
> specific implementation of unwind_user_fp_get_frame(), which uses the
> back chain.

> diff --git a/arch/s390/include/asm/unwind_user.h b/arch/s390/include/asm/unwind_user.h

> +static inline int unwind_user_fp_get_frame(struct unwind_user_state *state,
> +					   struct unwind_user_frame *frame)
> +{
> +	struct stack_frame_user __user *sf;
> +	unsigned long __user *ra_addr;
> +	unsigned long sp;
> +
> +	sf = (void __user *)state->sp;
> +
> +	/*
> +	 * In topmost frame check whether IP in early prologue, RA and SP
> +	 * registers saved, and no new stack frame allocated.
> +	 */
> +	if (state->topmost) {
> +		unsigned long ra, ra_reg;
> +
> +		ra_addr = (unsigned long __user *)&sf->gprs[8];
> +		if (__get_user(ra, ra_addr))
> +			return -EINVAL;
> +		if (__get_user(sp, (unsigned long __user *)&sf->gprs[9]))
> +			return -EINVAL;
> +		if (unwind_user_get_ra_reg(&ra_reg))
> +			return -EINVAL;
> +		if (ra == ra_reg && sp == state->sp)
> +			goto done;
> +	}

I realized that this additional heuristic is flawed:

The topmost function may be past prologue, have allocated a new stack
frame, and called a function.  The callee may have saved its RA and SP
registers in the current stack frame, so that after the return from
function call, the heuristic would erroneously assume that the topmost
function is in early prologue and use the callee's RA and SP.

Instead of erroneously skipping the caller it might erroneously insert
a callee as caller.  I'll remove it again in the next version.

> +
> +	if (__get_user(sp, (unsigned long __user *)&sf->back_chain))
> +		return -EINVAL;
> +	if (!sp && ip_within_vdso(state->ip)) {
> +		/*
> +		 * Assume non-standard vDSO user wrapper stack frame.
> +		 * See vDSO user wrapper code for details.
> +		 */
> +		struct stack_frame_vdso_wrapper *sf_vdso = (void __user *)sf;
> +
> +		ra_addr = (unsigned long __user *)&sf_vdso->return_address;
> +		sf = (void __user *)((unsigned long)sf + STACK_FRAME_VDSO_OVERHEAD);
> +		if (__get_user(sp, (unsigned long __user *)&sf->back_chain))
> +			return -EINVAL;
> +	} else if (!sp) {
> +		/*
> +		 * Assume outermost frame reached. unwind_user_next_common()
> +		 * disregards all other fields in outermost frame.
> +		 */
> +		frame->outermost = false;

		frame->outermost = true;

> +		return 0;
> +	} else {
> +		/*
> +		 * Assume IP past prologue and new stack frame allocated.
> +		 * Follow back chain, which then equals the SP at entry.
> +		 * Skips caller if wrong in topmost frame.
> +		 */
> +		sf = (void __user *)sp;
> +		ra_addr = (unsigned long __user *)&sf->gprs[8];
> +	}
> +
> +done:
> +	frame->cfa_off = sp - state->sp + 160;
> +	frame->sp_off = -160;
> +	frame->fp.loc = UNWIND_USER_LOC_UNKNOWN;	/* Cannot unwind FP. */
> +	frame->use_fp = false;
> +	frame->ra.loc = UNWIND_USER_LOC_STACK;
> +	frame->ra.offset = (unsigned long)ra_addr - (state->sp + frame->cfa_off);
> +	frame->outermost = false;
> +
> +	return 0;
> +}
> +#define unwind_user_fp_get_frame unwind_user_fp_get_frame
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/


      reply	other threads:[~2025-12-12  9:22 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-08 17:15 [RFC PATCH v3 00/17] s390: SFrame user space unwinding Jens Remus
2025-12-08 17:15 ` [RFC PATCH v3 01/17] unwind_user: Enhance comments on get CFA, FP, and RA Jens Remus
2025-12-08 17:15 ` [RFC PATCH v3 02/17] unwind_user/fp: Use dummies instead of ifdef Jens Remus
2025-12-08 17:15 ` [RFC PATCH v3 03/17] x86/unwind_user: Guard unwind_user_word_size() by UNWIND_USER Jens Remus
2025-12-08 17:15 ` [RFC PATCH v3 04/17] x86/unwind_user: Simplify unwind_user_word_size() Jens Remus
2025-12-08 17:15 ` [RFC PATCH v3 05/17] s390: asm/dwarf.h should only be included in assembly files Jens Remus
2025-12-10 15:16   ` Heiko Carstens
2025-12-11  9:43     ` Jens Remus
2025-12-08 17:15 ` [RFC PATCH v3 06/17] s390/vdso: Avoid emitting DWARF CFI for non-vDSO Jens Remus
2025-12-08 17:15 ` [RFC PATCH v3 07/17] s390/vdso: Keep function symbols in vDSO Jens Remus
2025-12-08 17:15 ` [RFC PATCH v3 08/17] s390/vdso: Enable SFrame generation " Jens Remus
2025-12-08 17:15 ` [RFC PATCH v3 09/17] unwind_user: Enable archs that define CFA = SP_callsite + offset Jens Remus
2025-12-08 17:15 ` [RFC PATCH v3 10/17] unwind_user: Enable archs that pass RA in a register Jens Remus
2025-12-08 17:15 ` [RFC PATCH v3 11/17] unwind_user: Enable archs that save RA/FP in other registers Jens Remus
2025-12-08 17:15 ` [RFC PATCH v3 12/17] unwind_user/sframe: Enable archs with encoded SFrame CFA offsets Jens Remus
2025-12-08 17:15 ` [RFC PATCH v3 13/17] s390/ptrace: Provide frame_pointer() Jens Remus
2025-12-10 15:19   ` Heiko Carstens
2025-12-08 17:15 ` [RFC PATCH v3 14/17] s390/unwind_user/sframe: Enable HAVE_UNWIND_USER_SFRAME Jens Remus
2025-12-10 15:10   ` Heiko Carstens
2025-12-12  8:13     ` Jens Remus
2025-12-08 17:15 ` [RFC PATCH v3 15/17] unwind_user: Introduce FP/RA location unknown Jens Remus
2025-12-08 17:15 ` [RFC PATCH v3 16/17] unwind_user/fp: Use arch-specific helper to initialize FP frame Jens Remus
2025-12-08 17:15 ` [RFC PATCH v3 17/17] s390/unwind_user/fp: Enable back chain unwinding of user space Jens Remus
2025-12-12  9:21   ` Jens Remus [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e38c0be1-52af-49a0-8bbc-1148ad3cc32e@linux.ibm.com \
    --to=jremus@linux.ibm.com \
    --cc=acme@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=andrii@kernel.org \
    --cc=beaub@linux.microsoft.com \
    --cc=bpf@vger.kernel.org \
    --cc=codonell@redhat.com \
    --cc=dylanbhatch@google.com \
    --cc=fweimer@redhat.com \
    --cc=gor@linux.ibm.com \
    --cc=hca@linux.ibm.com \
    --cc=iii@linux.ibm.com \
    --cc=indu.bhagat@oracle.com \
    --cc=jemarch@gnu.org \
    --cc=jolsa@kernel.org \
    --cc=jpoimboe@kernel.org \
    --cc=kees@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mhiramat@kernel.org \
    --cc=mingo@kernel.org \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rostedt@kernel.org \
    --cc=sam@gentoo.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).