From: Jiri Olsa <jolsa@kernel.org>
To: Oleg Nesterov <oleg@redhat.com>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>
Cc: bpf@vger.kernel.org, Song Liu <songliubraving@fb.com>,
Yonghong Song <yhs@fb.com>,
John Fastabend <john.fastabend@gmail.com>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>,
"Borislav Petkov (AMD)" <bp@alien8.de>,
x86@kernel.org
Subject: [PATCH RFC bpf-next 3/3] selftests/bpf: Mark uprobe trigger functions with nocf_check attribute
Date: Mon, 18 Mar 2024 10:31:38 +0100 [thread overview]
Message-ID: <20240318093139.293497-4-jolsa@kernel.org> (raw)
In-Reply-To: <20240318093139.293497-1-jolsa@kernel.org>
Some distros seem to enable the -fcf-protection=branch by default,
which breaks our setup on first instruction of uprobe trigger
functions and place there endbr64 instruction.
Marking them with nocf_check attribute to skip that.
Adding -Wno-attributes for bench objects, becase nocf_check can
be used only when -fcf-protection=branch is enabled, otherwise
we get a warning and break compilation.
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
---
tools/include/linux/compiler.h | 4 ++++
tools/testing/selftests/bpf/Makefile | 2 +-
tools/testing/selftests/bpf/benchs/bench_trigger.c | 6 +++---
3 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/tools/include/linux/compiler.h b/tools/include/linux/compiler.h
index 7b65566f3e42..14038ce04ca4 100644
--- a/tools/include/linux/compiler.h
+++ b/tools/include/linux/compiler.h
@@ -58,6 +58,10 @@
#define noinline
#endif
+#ifndef __nocfcheck
+#define __nocfcheck __attribute__((nocf_check))
+#endif
+
/* Are two types/vars the same type (ignoring qualifiers)? */
#ifndef __same_type
# define __same_type(a, b) __builtin_types_compatible_p(typeof(a), typeof(b))
diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile
index e425a946276b..506d3d592093 100644
--- a/tools/testing/selftests/bpf/Makefile
+++ b/tools/testing/selftests/bpf/Makefile
@@ -726,7 +726,7 @@ $(OUTPUT)/test_cpp: test_cpp.cpp $(OUTPUT)/test_core_extern.skel.h $(BPFOBJ)
# Benchmark runner
$(OUTPUT)/bench_%.o: benchs/bench_%.c bench.h $(BPFOBJ)
$(call msg,CC,,$@)
- $(Q)$(CC) $(CFLAGS) -O2 -c $(filter %.c,$^) $(LDLIBS) -o $@
+ $(Q)$(CC) $(CFLAGS) -O2 -Wno-attributes -c $(filter %.c,$^) $(LDLIBS) -o $@
$(OUTPUT)/bench_rename.o: $(OUTPUT)/test_overhead.skel.h
$(OUTPUT)/bench_trigger.o: $(OUTPUT)/trigger_bench.skel.h
$(OUTPUT)/bench_ringbufs.o: $(OUTPUT)/ringbuf_bench.skel.h \
diff --git a/tools/testing/selftests/bpf/benchs/bench_trigger.c b/tools/testing/selftests/bpf/benchs/bench_trigger.c
index ace0d1011a8e..3aecc3ef74e9 100644
--- a/tools/testing/selftests/bpf/benchs/bench_trigger.c
+++ b/tools/testing/selftests/bpf/benchs/bench_trigger.c
@@ -137,7 +137,7 @@ static void trigger_fmodret_setup(void)
* GCC doesn't generate stack setup preample for these functions due to them
* having no input arguments and doing nothing in the body.
*/
-__weak void uprobe_target_nop(void)
+__nocfcheck __weak void uprobe_target_nop(void)
{
asm volatile ("nop");
}
@@ -146,7 +146,7 @@ __weak void opaque_noop_func(void)
{
}
-__weak int uprobe_target_push(void)
+__nocfcheck __weak int uprobe_target_push(void)
{
/* overhead of function call is negligible compared to uprobe
* triggering, so this shouldn't affect benchmark results much
@@ -155,7 +155,7 @@ __weak int uprobe_target_push(void)
return 1;
}
-__weak void uprobe_target_ret(void)
+__nocfcheck __weak void uprobe_target_ret(void)
{
asm volatile ("");
}
--
2.44.0
next prev parent reply other threads:[~2024-03-18 9:32 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-18 9:31 [PATCH RFC bpf-next 0/3] uprobe: uretprobe speed up Jiri Olsa
2024-03-18 9:31 ` [PATCH RFC bpf-next 1/3] uprobe: Add uretprobe syscall to speed up return probe Jiri Olsa
2024-03-18 14:22 ` Oleg Nesterov
2024-03-19 1:11 ` Andrii Nakryiko
2024-03-19 6:32 ` Oleg Nesterov
2024-03-19 16:20 ` Andrii Nakryiko
2024-03-19 10:54 ` Jiri Olsa
2024-03-18 9:31 ` [PATCH RFC bpf-next 2/3] selftests/bpf: Add uretprobe syscall test Jiri Olsa
2024-03-19 1:16 ` Andrii Nakryiko
2024-03-19 11:09 ` Jiri Olsa
2024-03-18 9:31 ` Jiri Olsa [this message]
2024-03-19 1:22 ` [PATCH RFC bpf-next 3/3] selftests/bpf: Mark uprobe trigger functions with nocf_check attribute Andrii Nakryiko
2024-03-19 11:11 ` Jiri Olsa
2024-03-22 13:40 ` Jiri Olsa
2024-03-19 10:25 ` [PATCH RFC bpf-next 4/3] uprobe: ensure sys_uretprobe uses sysret Oleg Nesterov
2024-03-19 11:08 ` Jiri Olsa
2024-03-19 16:25 ` Andrii Nakryiko
2024-03-19 16:38 ` Oleg Nesterov
2024-03-19 19:35 ` Jiri Olsa
2024-03-19 19:31 ` Jiri Olsa
2024-03-19 20:13 ` Andrii Nakryiko
2024-03-20 11:04 ` Jiri Olsa
2024-03-20 14:37 ` Oleg Nesterov
2024-03-20 15:28 ` Oleg Nesterov
2024-03-20 17:44 ` Andrii Nakryiko
2024-03-20 19:08 ` Jiri Olsa
2024-03-21 10:10 ` Oleg Nesterov
2024-03-21 9:59 ` Jiri Olsa
2024-03-21 10:17 ` Oleg Nesterov
2024-03-21 10:52 ` Jiri Olsa
2024-03-21 12:14 ` Oleg Nesterov
2024-03-21 20:29 ` Jiri Olsa
2024-03-22 8:48 ` Oleg Nesterov
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=20240318093139.293497-4-jolsa@kernel.org \
--to=jolsa@kernel.org \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bp@alien8.de \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=john.fastabend@gmail.com \
--cc=oleg@redhat.com \
--cc=peterz@infradead.org \
--cc=songliubraving@fb.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
--cc=yhs@fb.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.