From: Peter Zijlstra <peterz@infradead.org>
To: Indu Bhagat <indu.bhagat@oracle.com>
Cc: linux-toolchains@vger.kernel.org, daandemeyer@meta.com,
andrii@kernel.org, rostedt@goodmis.org, kris.van.hees@oracle.com,
elena.zannoni@oracle.com, nick.alcock@oracle.com
Subject: Re: [POC 5/5] x86_64: invoke SFrame based stack tracer for user space
Date: Tue, 2 May 2023 12:53:53 +0200 [thread overview]
Message-ID: <20230502105353.GO1597476@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20230501200410.3973453-6-indu.bhagat@oracle.com>
On Mon, May 01, 2023 at 01:04:10PM -0700, Indu Bhagat wrote:
> The task's sframe_state is allocated and initialized if a phdr with type
> PT_GNU_SFRAME is encountered for the binary.
>
> perf_callchain_user() will fall back on the frame pointer based stack
> trace approach if:
> - SFrame section for the main program is not found.
> - SFrame state for the task is either not setup or stale and cannot
> be refreshed.
>
> Finally, the sframe_state is cleaned up in release_task().
>
> Signed-off-by: Indu Bhagat <indu.bhagat@oracle.com>
> ---
> arch/x86/events/core.c | 51 ++++++++++++++++++++++++++++++++++++++++++
> fs/binfmt_elf.c | 39 ++++++++++++++++++++++++++++++++
> kernel/exit.c | 9 ++++++++
> 3 files changed, 99 insertions(+)
>
> diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
> index d096b04bf80e..4be9e826714a 100644
> --- a/arch/x86/events/core.c
> +++ b/arch/x86/events/core.c
> @@ -2860,11 +2860,54 @@ perf_callchain_user32(struct pt_regs *regs, struct perf_callchain_entry_ctx *ent
> }
> #endif
>
> +#ifdef CONFIG_USER_UNWINDER_SFRAME
> +
> +#include <sframe/sframe_unwind.h>
> +
> +/* Check if the specified task has SFrame unwind state set up. */
> +static inline bool check_sframe_state_p(struct task_struct *task)
> +{
> + bool sframe_ok = false;
> +
> + /* FIXME TODO - only current task can be unwinded at this time.
> + * Even for current tasks, following unknowns remain and hence, not
> + * handled:
> + * - dlopen / dlclose detection and update of sframe_state,
> + * - in general, any change in memory mappings.
> + */
> + if (task != current)
> + return false;
> +
> + if (!task->sframe_state)
> + return false;
> +
> + sframe_ok = (unwind_sframe_state_valid_p(task->sframe_state)
> + || unwind_sframe_state_ready_p(task->sframe_state));
Please; forget this style is even possible, it is horrific :/
> +
> + return sframe_ok;
> +}
> +
> +#else
> +/* Check if the specified task has SFrame unwind state set up. */
> +static inline bool check_sframe_state_p(struct task_struct *task)
> +{
> + return false;
> +}
> +
> +static inline int sframe_callchain_user(struct task_struct *task,
> + struct perf_callchain_entry_ctx *entry,
> + struct pt_regs *regs)
> +{
> + return 0;
> +}
> +#endif
> +
> void
> perf_callchain_user(struct perf_callchain_entry_ctx *entry, struct pt_regs *regs)
> {
> struct stack_frame frame;
> const struct stack_frame __user *fp;
> + bool sframe_avail;
>
> if (perf_guest_state()) {
> /* TODO: We don't support guest os callchain now */
> @@ -2887,7 +2930,15 @@ perf_callchain_user(struct perf_callchain_entry_ctx *entry, struct pt_regs *regs
> if (perf_callchain_user32(regs, entry))
> return;
>
> + sframe_avail = check_sframe_state_p (current);
> +
> pagefault_disable();
> +
> + if (sframe_avail && !sframe_callchain_user (current, entry, regs)) {
> + pagefault_enable();
> + return;
> + }
> +
> while (entry->nr < entry->max_stack) {
> if (!valid_user_frame(fp, sizeof(frame)))
> break;
This is broken, the sframe stuff is not NMI safe. First you need to
change perf to emit a forward reference to a 'next' user trace and then
emit the user trace on return-to-user.
As is, perf does everything in-place from NMI context.
next prev parent reply other threads:[~2023-05-02 10:54 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-01 20:04 [POC 0/5] SFrame based stack tracer for user space in the kernel Indu Bhagat
2023-05-01 20:04 ` [POC 1/5] Kconfig: x86: Add new config options for userspace unwinder Indu Bhagat
2023-05-01 20:04 ` [POC 2/5] task_struct : add additional member for sframe state Indu Bhagat
2023-05-01 20:04 ` [POC 3/5] sframe: add new SFrame library Indu Bhagat
2023-05-01 22:40 ` Steven Rostedt
2023-05-02 5:07 ` Indu Bhagat
2023-05-02 8:46 ` Peter Zijlstra
2023-05-02 9:09 ` Peter Zijlstra
2023-05-02 9:20 ` Peter Zijlstra
2023-05-02 9:28 ` Peter Zijlstra
2023-05-02 9:30 ` Peter Zijlstra
2023-05-03 6:03 ` Indu Bhagat
2023-05-02 10:31 ` Peter Zijlstra
2023-05-02 10:41 ` Peter Zijlstra
2023-05-02 15:22 ` Steven Rostedt
2023-05-01 20:04 ` [POC 4/5] sframe: add an SFrame format stack tracer Indu Bhagat
2023-05-01 23:00 ` Steven Rostedt
2023-05-02 6:16 ` Indu Bhagat
2023-05-02 8:53 ` Peter Zijlstra
2023-05-02 9:04 ` Peter Zijlstra
2023-05-01 20:04 ` [POC 5/5] x86_64: invoke SFrame based stack tracer for user space Indu Bhagat
2023-05-01 23:11 ` Steven Rostedt
2023-05-02 10:53 ` Peter Zijlstra [this message]
2023-05-02 15:27 ` Steven Rostedt
2023-05-16 17:25 ` Andrii Nakryiko
2023-05-16 17:38 ` Steven Rostedt
2023-05-16 17:51 ` Andrii Nakryiko
2024-03-13 14:37 ` Tatsuyuki Ishi
2024-03-13 14:52 ` Steven Rostedt
2024-03-13 14:58 ` Tatsuyuki Ishi
2024-03-13 15:04 ` Steven Rostedt
2023-05-01 22:15 ` [POC 0/5] SFrame based stack tracer for user space in the kernel Steven Rostedt
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=20230502105353.GO1597476@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=andrii@kernel.org \
--cc=daandemeyer@meta.com \
--cc=elena.zannoni@oracle.com \
--cc=indu.bhagat@oracle.com \
--cc=kris.van.hees@oracle.com \
--cc=linux-toolchains@vger.kernel.org \
--cc=nick.alcock@oracle.com \
--cc=rostedt@goodmis.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).