linux-toolchains.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mark Rutland <mark.rutland@arm.com>
To: Song Liu <song@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-toolchains@vger.kernel.org,
	live-patching@vger.kernel.org, indu.bhagat@oracle.com,
	puranjay@kernel.org, wnliu@google.com, irogers@google.com,
	joe.lawrence@redhat.com, jpoimboe@kernel.org,
	peterz@infradead.org, roman.gushchin@linux.dev,
	rostedt@goodmis.org, will@kernel.org, kernel-team@meta.com
Subject: Re: [PATCH v3 1/2] arm64: Implement arch_stack_walk_reliable
Date: Mon, 19 May 2025 14:41:06 +0100	[thread overview]
Message-ID: <aCs08i3u9C9MWy4M@J2N7QTR9R3> (raw)
In-Reply-To: <20250320171559.3423224-2-song@kernel.org>

On Thu, Mar 20, 2025 at 10:15:58AM -0700, Song Liu wrote:
> With proper exception boundary detection, it is possible to implment
> arch_stack_walk_reliable without sframe.
> 
> Note that, arch_stack_walk_reliable does not guarantee getting reliable
> stack in all scenarios. Instead, it can reliably detect when the stack
> trace is not reliable, which is enough to provide reliable livepatching.
> 
> Signed-off-by: Song Liu <song@kernel.org>
> ---
>  arch/arm64/Kconfig             |  2 +-
>  arch/arm64/kernel/stacktrace.c | 66 +++++++++++++++++++++++++---------
>  2 files changed, 51 insertions(+), 17 deletions(-)
> 
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 701d980ea921..31d5e1ee6089 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -276,6 +276,7 @@ config ARM64
>  	select HAVE_SOFTIRQ_ON_OWN_STACK
>  	select USER_STACKTRACE_SUPPORT
>  	select VDSO_GETRANDOM
> +	select HAVE_RELIABLE_STACKTRACE
>  	help
>  	  ARM 64-bit (AArch64) Linux support.
>  
> @@ -2500,4 +2501,3 @@ endmenu # "CPU Power Management"
>  source "drivers/acpi/Kconfig"
>  
>  source "arch/arm64/kvm/Kconfig"
> -
> diff --git a/arch/arm64/kernel/stacktrace.c b/arch/arm64/kernel/stacktrace.c
> index 1d9d51d7627f..7e07911d8694 100644
> --- a/arch/arm64/kernel/stacktrace.c
> +++ b/arch/arm64/kernel/stacktrace.c
> @@ -56,6 +56,7 @@ struct kunwind_state {
>  	enum kunwind_source source;
>  	union unwind_flags flags;
>  	struct pt_regs *regs;
> +	bool end_on_unreliable;
>  };
>  
>  static __always_inline void
> @@ -230,8 +231,26 @@ kunwind_next_frame_record(struct kunwind_state *state)
>  	new_fp = READ_ONCE(record->fp);
>  	new_pc = READ_ONCE(record->lr);
>  
> -	if (!new_fp && !new_pc)
> -		return kunwind_next_frame_record_meta(state);
> +	if (!new_fp && !new_pc) {
> +		int ret;
> +
> +		ret = kunwind_next_frame_record_meta(state);
> +		if (ret < 0) {
> +			/*
> +			 * This covers two different conditions:
> +			 *  1. ret == -ENOENT, unwinding is done.
> +			 *  2. ret == -EINVAL, unwinding hit error.
> +			 */
> +			return ret;
> +		}
> +		/*
> +		 * Searching across exception boundaries. The stack is now
> +		 * unreliable.
> +		 */
> +		if (state->end_on_unreliable)
> +			return -EINVAL;
> +		return 0;
> +	}

My original expectation for this this was that we'd propogate the
errors, and then all the reliability logic would live un a consume_entry
wrapper like we have for BPF, e.g.

| static __always_inline bool
| arch_reliable_kunwind_consume_entry(const struct kunwind_state *state, void *cookie)
| {
|         struct kunwind_consume_entry_data *data = cookie;
| 
|         /*  
|          * When unwinding across an exception boundary, the PC will be
|          * reliable, but we do not know whether the FP is live, and so we
|          * cannot perform the *next* unwind reliably.
|          *
|          * Give up as soon as we hit an exception boundary.
|          */
|         if (state->source == KUNWIND_SOURCE_REGS_PC)
|                 return false;
| 
|         return data->consume_entry(data->cookie, state->common.pc);
| }
| 
| noinline noinstr int arch_stack_walk_reliable(stack_trace_consume_fn consume_entry,
|                                               void *cookie,
|                                               struct task_struct *task)
| {
|         int ret;
|         struct kunwind_consume_entry_data data = { 
|                 .consume_entry = consume_entry,
|                 .cookie = cookie,
|         };  
| 
|         ret = kunwind_stack_walk(arch_reliable_kunwind_consume_entry, &data,
|                                  task, NULL);
|         return ret == -ENOENT ? 0 : ret;
| }

... and then in future we can add anything spdecific to reliable
stacktrace there.

That aside, this generally looks good to me. The only thing that I note
is that we're lacking a check on the return value of
kretprobe_find_ret_addr(), and we should return -EINVAL when that is
NULL, but that should never happen in normal operation.

I've pushed a arm64/stacktrace-updates branch [1] with fixups for those
as two separate commits atop this one. If that looks good to you I
suggest we post that as a series and ask Will and Catalin to take that
as-is.

I'll look at the actual patching bits now.

Mark.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/ arm64/stacktrace-updates

  parent reply	other threads:[~2025-05-19 13:41 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-20 17:15 [PATCH v3 0/2] arm64: livepatch: Enable livepatch without sframe Song Liu
2025-03-20 17:15 ` [PATCH v3 1/2] arm64: Implement arch_stack_walk_reliable Song Liu
2025-03-20 17:46   ` Weinan Liu
2025-03-20 17:54     ` Song Liu
2025-03-21  7:11   ` Josh Poimboeuf
2025-03-26 13:48   ` Miroslav Benes
2025-03-31  9:06   ` Andrea della Porta
2025-05-19 13:41   ` Mark Rutland [this message]
2025-05-19 16:57     ` Song Liu
2025-05-20 14:28     ` Will Deacon
2025-05-20 16:59       ` Mark Rutland
2025-03-20 17:15 ` [PATCH v3 2/2] arm64: Implement HAVE_LIVEPATCH Song Liu
2025-03-31  9:07   ` Andrea della Porta
2025-03-25 12:53 ` [PATCH v3 0/2] arm64: livepatch: Enable livepatch without sframe Petr Mladek
2025-03-25 13:37   ` Song Liu
2025-04-10 15:17 ` Petr Mladek
2025-05-16 16:53   ` Song Liu
2025-05-19 12:57     ` Mark Rutland
2025-05-19 14:22     ` Will Deacon
2025-05-19 16:40     ` Mark Rutland
2025-05-19 17:11       ` Dylan Hatch

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=aCs08i3u9C9MWy4M@J2N7QTR9R3 \
    --to=mark.rutland@arm.com \
    --cc=indu.bhagat@oracle.com \
    --cc=irogers@google.com \
    --cc=joe.lawrence@redhat.com \
    --cc=jpoimboe@kernel.org \
    --cc=kernel-team@meta.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-toolchains@vger.kernel.org \
    --cc=live-patching@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=puranjay@kernel.org \
    --cc=roman.gushchin@linux.dev \
    --cc=rostedt@goodmis.org \
    --cc=song@kernel.org \
    --cc=will@kernel.org \
    --cc=wnliu@google.com \
    /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).