All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Florent Revest <revest@chromium.org>
Cc: Xu Kuohai <xukuohai@huawei.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Xu Kuohai <xukuohai@huaweicloud.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, bpf@vger.kernel.org,
	Will Deacon <will@kernel.org>,
	Jean-Philippe Brucker <jean-philippe@linaro.org>,
	Ingo Molnar <mingo@redhat.com>, Oleg Nesterov <oleg@redhat.com>,
	Alexei Starovoitov <ast@kernel.org>,
	Andrii Nakryiko <andrii@kernel.org>,
	Martin KaFai Lau <martin.lau@linux.dev>,
	Song Liu <song@kernel.org>, Yonghong Song <yhs@fb.com>,
	John Fastabend <john.fastabend@gmail.com>,
	KP Singh <kpsingh@kernel.org>,
	Stanislav Fomichev <sdf@google.com>, Hao Luo <haoluo@google.com>,
	Jiri Olsa <jolsa@kernel.org>, Zi Shen Lim <zlim.lnx@gmail.com>,
	Pasha Tatashin <pasha.tatashin@soleen.com>,
	Ard Biesheuvel <ardb@kernel.org>, Marc Zyngier <maz@kernel.org>,
	Guo Ren <guoren@kernel.org>,
	Masami Hiramatsu <mhiramat@kernel.org>
Subject: Re: [PATCH bpf-next v2 0/4] Add ftrace direct call for arm64
Date: Mon, 17 Oct 2022 14:49:49 -0400	[thread overview]
Message-ID: <20221017144949.2b9dcdc5@gandalf.local.home> (raw)
In-Reply-To: <CABRcYm+d=xY9nBCJo-6JW_=F41g4X32QM9WOPChaOTfs6d6KCA@mail.gmail.com>

On Mon, 17 Oct 2022 19:55:06 +0200
Florent Revest <revest@chromium.org> wrote:

> Note that I can't really make sense of the perf report with indirect
> calls. it always reports it spent 12% of the time in
> rethook_trampoline_handler but I verified with both a WARN in that
> function and a breakpoint with a debugger, this function does *not*
> get called when running this "bench trig-fentry" benchmark. Also it
> wouldn't make sense for fprobe_handler to call it so I'm quite
> confused why perf would report this call and such a long time spent
> there. Anyone know what I could be missing here ?

The trace shows __bpf_prog_exit, which I'm guessing is tracing the end of
the function. Right?

In which case I believe it must call rethook_trampoline_handler:

 -> fprobe_handler() /* Which could use some "unlikely()" to move disabled
                        paths out of the hot path */

       /* And also calls rethook_try_get () which does a cmpxchg! */

	-> ret_hook()
		-> arch_rethook_prepare()
			Sets regs->lr = arch_rethook_trampoline

On return of the function, it jumps to arch_rethook_trampoline()

  -> arch_rethook_trampoline()
	-> arch_rethook_trampoline_callback()
		-> rethook_trampoline_handler()

So I do not know how it wouldn't trigger the WARNING or breakpoint if you
added it there.

-- Steve

WARNING: multiple messages have this Message-ID (diff)
From: Steven Rostedt <rostedt@goodmis.org>
To: Florent Revest <revest@chromium.org>
Cc: Xu Kuohai <xukuohai@huawei.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Xu Kuohai <xukuohai@huaweicloud.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, bpf@vger.kernel.org,
	Will Deacon <will@kernel.org>,
	Jean-Philippe Brucker <jean-philippe@linaro.org>,
	Ingo Molnar <mingo@redhat.com>, Oleg Nesterov <oleg@redhat.com>,
	Alexei Starovoitov <ast@kernel.org>,
	Andrii Nakryiko <andrii@kernel.org>,
	Martin KaFai Lau <martin.lau@linux.dev>,
	Song Liu <song@kernel.org>, Yonghong Song <yhs@fb.com>,
	John Fastabend <john.fastabend@gmail.com>,
	KP Singh <kpsingh@kernel.org>,
	Stanislav Fomichev <sdf@google.com>, Hao Luo <haoluo@google.com>,
	Jiri Olsa <jolsa@kernel.org>, Zi Shen Lim <zlim.lnx@gmail.com>,
	Pasha Tatashin <pasha.tatashin@soleen.com>,
	Ard Biesheuvel <ardb@kernel.org>, Marc Zyngier <maz@kernel.org>,
	Guo Ren <guoren@kernel.org>,
	Masami Hiramatsu <mhiramat@kernel.org>
Subject: Re: [PATCH bpf-next v2 0/4] Add ftrace direct call for arm64
Date: Mon, 17 Oct 2022 14:49:49 -0400	[thread overview]
Message-ID: <20221017144949.2b9dcdc5@gandalf.local.home> (raw)
In-Reply-To: <CABRcYm+d=xY9nBCJo-6JW_=F41g4X32QM9WOPChaOTfs6d6KCA@mail.gmail.com>

On Mon, 17 Oct 2022 19:55:06 +0200
Florent Revest <revest@chromium.org> wrote:

> Note that I can't really make sense of the perf report with indirect
> calls. it always reports it spent 12% of the time in
> rethook_trampoline_handler but I verified with both a WARN in that
> function and a breakpoint with a debugger, this function does *not*
> get called when running this "bench trig-fentry" benchmark. Also it
> wouldn't make sense for fprobe_handler to call it so I'm quite
> confused why perf would report this call and such a long time spent
> there. Anyone know what I could be missing here ?

The trace shows __bpf_prog_exit, which I'm guessing is tracing the end of
the function. Right?

In which case I believe it must call rethook_trampoline_handler:

 -> fprobe_handler() /* Which could use some "unlikely()" to move disabled
                        paths out of the hot path */

       /* And also calls rethook_try_get () which does a cmpxchg! */

	-> ret_hook()
		-> arch_rethook_prepare()
			Sets regs->lr = arch_rethook_trampoline

On return of the function, it jumps to arch_rethook_trampoline()

  -> arch_rethook_trampoline()
	-> arch_rethook_trampoline_callback()
		-> rethook_trampoline_handler()

So I do not know how it wouldn't trigger the WARNING or breakpoint if you
added it there.

-- Steve

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-10-17 18:49 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-13 16:27 [PATCH bpf-next v2 0/4] Add ftrace direct call for arm64 Xu Kuohai
2022-09-13 16:27 ` Xu Kuohai
2022-09-13 16:27 ` [PATCH bpf-next v2 1/4] ftrace: Allow users to disable ftrace direct call Xu Kuohai
2022-09-13 16:27   ` Xu Kuohai
2022-09-13 16:27 ` [PATCH bpf-next v2 2/4] arm64: ftrace: Support long jump for " Xu Kuohai
2022-09-13 16:27   ` Xu Kuohai
2022-09-13 16:27 ` [PATCH bpf-next v2 3/4] arm64: ftrace: Add ftrace direct call support Xu Kuohai
2022-09-13 16:27   ` Xu Kuohai
2022-09-13 16:27 ` [PATCH bpf-next v2 4/4] ftrace: Fix dead loop caused by direct call in ftrace selftest Xu Kuohai
2022-09-13 16:27   ` Xu Kuohai
2022-09-22 18:01 ` [PATCH bpf-next v2 0/4] Add ftrace direct call for arm64 Daniel Borkmann
2022-09-22 18:01   ` Daniel Borkmann
2022-09-26 14:40   ` Catalin Marinas
2022-09-26 14:40     ` Catalin Marinas
2022-09-26 17:43     ` Mark Rutland
2022-09-26 17:43       ` Mark Rutland
2022-09-27  4:49       ` Xu Kuohai
2022-09-27  4:49         ` Xu Kuohai
2022-09-28 16:42         ` Mark Rutland
2022-09-28 16:42           ` Mark Rutland
2022-09-30  4:07           ` Xu Kuohai
2022-09-30  4:07             ` Xu Kuohai
2022-10-04 16:06             ` Florent Revest
2022-10-04 16:06               ` Florent Revest
2022-10-05 14:54               ` Xu Kuohai
2022-10-05 14:54                 ` Xu Kuohai
2022-10-05 15:07                 ` Steven Rostedt
2022-10-05 15:07                   ` Steven Rostedt
2022-10-05 15:10                   ` Florent Revest
2022-10-05 15:10                     ` Florent Revest
2022-10-05 15:30                     ` Steven Rostedt
2022-10-05 15:30                       ` Steven Rostedt
2022-10-05 22:12                       ` Jiri Olsa
2022-10-05 22:12                         ` Jiri Olsa
2022-10-06 16:35                         ` Florent Revest
2022-10-06 16:35                           ` Florent Revest
2022-10-06 10:09                       ` Xu Kuohai
2022-10-06 10:09                         ` Xu Kuohai
2022-10-06 16:19                       ` Florent Revest
2022-10-06 16:19                         ` Florent Revest
2022-10-06 16:29                         ` Steven Rostedt
2022-10-06 16:29                           ` Steven Rostedt
2022-10-07 10:13                           ` Xu Kuohai
2022-10-07 10:13                             ` Xu Kuohai
2022-10-17 17:55                           ` Florent Revest
2022-10-17 17:55                             ` Florent Revest
2022-10-17 18:49                             ` Steven Rostedt [this message]
2022-10-17 18:49                               ` Steven Rostedt
2022-10-17 19:10                               ` Florent Revest
2022-10-17 19:10                                 ` Florent Revest
2022-10-21 11:31                             ` Masami Hiramatsu
2022-10-21 11:31                               ` Masami Hiramatsu
2022-10-21 16:49                               ` Florent Revest
2022-10-21 16:49                                 ` Florent Revest
2022-10-24 13:00                                 ` Masami Hiramatsu
2022-10-24 13:00                                   ` Masami Hiramatsu
2022-11-10  4:58                                 ` wuqiang
2022-11-10  4:58                                   ` wuqiang
2022-10-06 10:09           ` Xu Kuohai
2022-10-06 10:09             ` Xu Kuohai

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=20221017144949.2b9dcdc5@gandalf.local.home \
    --to=rostedt@goodmis.org \
    --cc=andrii@kernel.org \
    --cc=ardb@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=daniel@iogearbox.net \
    --cc=guoren@kernel.org \
    --cc=haoluo@google.com \
    --cc=jean-philippe@linaro.org \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=kpsingh@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=martin.lau@linux.dev \
    --cc=maz@kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=mingo@redhat.com \
    --cc=oleg@redhat.com \
    --cc=pasha.tatashin@soleen.com \
    --cc=revest@chromium.org \
    --cc=sdf@google.com \
    --cc=song@kernel.org \
    --cc=will@kernel.org \
    --cc=xukuohai@huawei.com \
    --cc=xukuohai@huaweicloud.com \
    --cc=yhs@fb.com \
    --cc=zlim.lnx@gmail.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 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.