From: chenqiwu <qiwuchen55@gmail.com>
To: Will Deacon <will@kernel.org>
Cc: chenqiwu <qiwuchen55@gmail.com>,
catalin.marinas@arm.com, peterz@infradead.org, mingo@redhat.com,
mark.rutland@arm.com, jolsa@kernel.org, namhyung@kernel.org,
irogers@google.com, adrian.hunter@intel.com,
kaleshsingh@google.com, ardb@kernel.org,
alexander.shishkin@linux.intel.com,
linux-arm-kernel@lists.infradead.org,
linux-perf-users@vger.kernel.org
Subject: Re: [RESEND v3] arm64: Add USER_STACKTRACE support
Date: Wed, 24 Apr 2024 22:11:35 +0800 [thread overview]
Message-ID: <20240424141135.GA3664@rlk> (raw)
In-Reply-To: <20240419130921.GA3148@willie-the-truck>
On Fri, Apr 19, 2024 at 02:09:21PM +0100, Will Deacon wrote:
> On Tue, Dec 19, 2023 at 10:22:29AM +0800, chenqiwu wrote:
> > Currently, userstacktrace is unsupported for ftrace and uprobe
> > tracers on arm64. This patch uses the perf_callchain_user() code
> > as blueprint to implement the arch_stack_walk_user() which add
> > userstacktrace support on arm64.
> > Meanwhile, we can use arch_stack_walk_user() to simplify the
> > implementation of perf_callchain_user().
> > This patch is tested pass with ftrace, uprobe and perf tracers
> > profiling userstacktrace cases.
> >
> > changes in v3:
> > - update perf_callchain_user() to use arch_stack_walk_user()
> > and delete the redundant code as Mark's suggestion in v2.
> > - update the commit message.
> >
> > Tested-by: chenqiwu <qiwu.chen@transsion.com>
> > Signed-off-by: chenqiwu <qiwu.chen@transsion.com>
> > ---
> > arch/arm64/Kconfig | 1 +
> > arch/arm64/kernel/perf_callchain.c | 118 +---------------------------
> > arch/arm64/kernel/stacktrace.c | 120 +++++++++++++++++++++++++++++
> > 3 files changed, 125 insertions(+), 114 deletions(-)
>
> This mostly looks good to me, with one potential issue:
>
> > @@ -107,35 +25,7 @@ void perf_callchain_user(struct perf_callchain_entry_ctx *entry,
> > return;
> > }
> >
> > - perf_callchain_store(entry, regs->pc);
> > -
> > - if (!compat_user_mode(regs)) {
> > - /* AARCH64 mode */
> > - struct frame_tail __user *tail;
> > -
> > - tail = (struct frame_tail __user *)regs->regs[29];
> > -
> > - while (entry->nr < entry->max_stack &&
>
> The old code is checking entry->nr against entry->max_stack here...
>
> > +void arch_stack_walk_user(stack_trace_consume_fn consume_entry, void *cookie,
> > + const struct pt_regs *regs)
> > +{
> > + if (!consume_entry(cookie, regs->pc))
> > + return;
> > +
> > + if (!compat_user_mode(regs)) {
> > + /* AARCH64 mode */
> > + struct frame_tail __user *tail;
> > +
> > + tail = (struct frame_tail __user *)regs->regs[29];
> > + while (tail && !((unsigned long)tail & 0x7))
> > + tail = unwind_user_frame(tail, cookie, consume_entry);
>
> ... but it looks like you've dropped that with the rework. Why is that ok?
>
It's no necessary to check entry->nr in arch_stack_walk_user(), because the caller function
stack_trace_save_user() registers the consume_entry callback for saving user stack traces into
a storage array, checking entry->nr against entry->max_stack is put into stack_trace_consume_entry().
Qiwu
WARNING: multiple messages have this Message-ID (diff)
From: chenqiwu <qiwuchen55@gmail.com>
To: Will Deacon <will@kernel.org>
Cc: chenqiwu <qiwuchen55@gmail.com>,
catalin.marinas@arm.com, peterz@infradead.org, mingo@redhat.com,
mark.rutland@arm.com, jolsa@kernel.org, namhyung@kernel.org,
irogers@google.com, adrian.hunter@intel.com,
kaleshsingh@google.com, ardb@kernel.org,
alexander.shishkin@linux.intel.com,
linux-arm-kernel@lists.infradead.org,
linux-perf-users@vger.kernel.org
Subject: Re: [RESEND v3] arm64: Add USER_STACKTRACE support
Date: Wed, 24 Apr 2024 22:11:35 +0800 [thread overview]
Message-ID: <20240424141135.GA3664@rlk> (raw)
In-Reply-To: <20240419130921.GA3148@willie-the-truck>
On Fri, Apr 19, 2024 at 02:09:21PM +0100, Will Deacon wrote:
> On Tue, Dec 19, 2023 at 10:22:29AM +0800, chenqiwu wrote:
> > Currently, userstacktrace is unsupported for ftrace and uprobe
> > tracers on arm64. This patch uses the perf_callchain_user() code
> > as blueprint to implement the arch_stack_walk_user() which add
> > userstacktrace support on arm64.
> > Meanwhile, we can use arch_stack_walk_user() to simplify the
> > implementation of perf_callchain_user().
> > This patch is tested pass with ftrace, uprobe and perf tracers
> > profiling userstacktrace cases.
> >
> > changes in v3:
> > - update perf_callchain_user() to use arch_stack_walk_user()
> > and delete the redundant code as Mark's suggestion in v2.
> > - update the commit message.
> >
> > Tested-by: chenqiwu <qiwu.chen@transsion.com>
> > Signed-off-by: chenqiwu <qiwu.chen@transsion.com>
> > ---
> > arch/arm64/Kconfig | 1 +
> > arch/arm64/kernel/perf_callchain.c | 118 +---------------------------
> > arch/arm64/kernel/stacktrace.c | 120 +++++++++++++++++++++++++++++
> > 3 files changed, 125 insertions(+), 114 deletions(-)
>
> This mostly looks good to me, with one potential issue:
>
> > @@ -107,35 +25,7 @@ void perf_callchain_user(struct perf_callchain_entry_ctx *entry,
> > return;
> > }
> >
> > - perf_callchain_store(entry, regs->pc);
> > -
> > - if (!compat_user_mode(regs)) {
> > - /* AARCH64 mode */
> > - struct frame_tail __user *tail;
> > -
> > - tail = (struct frame_tail __user *)regs->regs[29];
> > -
> > - while (entry->nr < entry->max_stack &&
>
> The old code is checking entry->nr against entry->max_stack here...
>
> > +void arch_stack_walk_user(stack_trace_consume_fn consume_entry, void *cookie,
> > + const struct pt_regs *regs)
> > +{
> > + if (!consume_entry(cookie, regs->pc))
> > + return;
> > +
> > + if (!compat_user_mode(regs)) {
> > + /* AARCH64 mode */
> > + struct frame_tail __user *tail;
> > +
> > + tail = (struct frame_tail __user *)regs->regs[29];
> > + while (tail && !((unsigned long)tail & 0x7))
> > + tail = unwind_user_frame(tail, cookie, consume_entry);
>
> ... but it looks like you've dropped that with the rework. Why is that ok?
>
It's no necessary to check entry->nr in arch_stack_walk_user(), because the caller function
stack_trace_save_user() registers the consume_entry callback for saving user stack traces into
a storage array, checking entry->nr against entry->max_stack is put into stack_trace_consume_entry().
Qiwu
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2024-04-24 14:11 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-19 2:22 [RESEND v3] arm64: Add USER_STACKTRACE support chenqiwu
2023-12-19 2:22 ` chenqiwu
2024-04-19 13:09 ` Will Deacon
2024-04-19 13:09 ` Will Deacon
2024-04-24 14:11 ` chenqiwu [this message]
2024-04-24 14:11 ` chenqiwu
2024-05-03 13:08 ` Will Deacon
2024-05-03 13:08 ` Will Deacon
2024-05-03 17:32 ` Will Deacon
2024-05-03 17:32 ` Will Deacon
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=20240424141135.GA3664@rlk \
--to=qiwuchen55@gmail.com \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=ardb@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=irogers@google.com \
--cc=jolsa@kernel.org \
--cc=kaleshsingh@google.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=will@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.