* [PATCH bpf-next 0/2] bpf,ftrace: bpf dispatcher function fix
@ 2022-08-26 18:46 Jiri Olsa
2022-08-26 18:46 ` [PATCH bpf-next 1/2] ftrace: Add HAVE_DYNAMIC_FTRACE_NO_PATCHABLE Jiri Olsa
` (2 more replies)
0 siblings, 3 replies; 11+ messages in thread
From: Jiri Olsa @ 2022-08-26 18:46 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko
Cc: bpf, Martin KaFai Lau, Song Liu, Yonghong Song, John Fastabend,
KP Singh, Stanislav Fomichev, Hao Luo, Peter Zijlstra,
Thomas Gleixner, Björn Töpel
hi,
as discussed [1] sending fix that moves bpf dispatcher function of out
ftrace locations together with Peter's HAVE_DYNAMIC_FTRACE_NO_PATCHABLE
dependency change.
thanks,
jirka
[1] https://lore.kernel.org/bpf/20220722110811.124515-1-jolsa@kernel.org/
---
Jiri Olsa (1):
bpf: Move bpf_dispatcher function out of ftrace locations
Peter Zijlstra (Intel) (1):
ftrace: Add HAVE_DYNAMIC_FTRACE_NO_PATCHABLE
arch/x86/Kconfig | 1 +
include/asm-generic/vmlinux.lds.h | 11 ++++++++++-
include/linux/bpf.h | 2 ++
kernel/trace/Kconfig | 6 ++++++
tools/objtool/check.c | 3 ++-
5 files changed, 21 insertions(+), 2 deletions(-)
^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH bpf-next 1/2] ftrace: Add HAVE_DYNAMIC_FTRACE_NO_PATCHABLE
2022-08-26 18:46 [PATCH bpf-next 0/2] bpf,ftrace: bpf dispatcher function fix Jiri Olsa
@ 2022-08-26 18:46 ` Jiri Olsa
2022-08-26 18:46 ` [PATCH bpf-next 2/2] bpf: Move bpf_dispatcher function out of ftrace locations Jiri Olsa
2022-08-29 22:25 ` [PATCH bpf-next 0/2] bpf,ftrace: bpf dispatcher function fix Daniel Borkmann
2 siblings, 0 replies; 11+ messages in thread
From: Jiri Olsa @ 2022-08-26 18:46 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko
Cc: bpf, Martin KaFai Lau, Song Liu, Yonghong Song, John Fastabend,
KP Singh, Stanislav Fomichev, Hao Luo, Peter Zijlstra,
Thomas Gleixner, Björn Töpel
From: "Peter Zijlstra (Intel)" <peterz@infradead.org>
x86 will shortly start using -fpatchable-function-entry for purposes
other than ftrace, make sure the __patchable_function_entry section
isn't merged in the mcount_loc section.
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
---
include/asm-generic/vmlinux.lds.h | 11 ++++++++++-
kernel/trace/Kconfig | 6 ++++++
tools/objtool/check.c | 3 ++-
3 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index 7515a465ec03..13b197ef0d63 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -154,6 +154,14 @@
#define MEM_DISCARD(sec) *(.mem##sec)
#endif
+#ifndef CONFIG_HAVE_DYNAMIC_FTRACE_NO_PATCHABLE
+#define KEEP_PATCHABLE KEEP(*(__patchable_function_entries))
+#define PATCHABLE_DISCARDS
+#else
+#define KEEP_PATCHABLE
+#define PATCHABLE_DISCARDS *(__patchable_function_entries)
+#endif
+
#ifdef CONFIG_FTRACE_MCOUNT_RECORD
/*
* The ftrace call sites are logged to a section whose name depends on the
@@ -172,7 +180,7 @@
#define MCOUNT_REC() . = ALIGN(8); \
__start_mcount_loc = .; \
KEEP(*(__mcount_loc)) \
- KEEP(*(__patchable_function_entries)) \
+ KEEP_PATCHABLE \
__stop_mcount_loc = .; \
ftrace_stub_graph = ftrace_stub; \
ftrace_ops_list_func = arch_ftrace_ops_list_func;
@@ -1024,6 +1032,7 @@
#define COMMON_DISCARDS \
SANITIZER_DISCARDS \
+ PATCHABLE_DISCARDS \
*(.discard) \
*(.discard.*) \
*(.modinfo) \
diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
index 1052126bdca2..e9e95c790b8e 100644
--- a/kernel/trace/Kconfig
+++ b/kernel/trace/Kconfig
@@ -51,6 +51,12 @@ config HAVE_DYNAMIC_FTRACE_WITH_ARGS
This allows for use of regs_get_kernel_argument() and
kernel_stack_pointer().
+config HAVE_DYNAMIC_FTRACE_NO_PATCHABLE
+ bool
+ help
+ If the architecture generates __patchable_function_entries sections
+ but does not want them included in the ftrace locations.
+
config HAVE_FTRACE_MCOUNT_RECORD
bool
help
diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index 0cec74da7ffe..f23e8d11f6d4 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -4110,7 +4110,8 @@ static int validate_ibt(struct objtool_file *file)
!strcmp(sec->name, "__bug_table") ||
!strcmp(sec->name, "__ex_table") ||
!strcmp(sec->name, "__jump_table") ||
- !strcmp(sec->name, "__mcount_loc"))
+ !strcmp(sec->name, "__mcount_loc") ||
+ strstr(sec->name, "__patchable_function_entries"))
continue;
list_for_each_entry(reloc, &sec->reloc->reloc_list, list)
--
2.37.2
^ permalink raw reply related [flat|nested] 11+ messages in thread
* [PATCH bpf-next 2/2] bpf: Move bpf_dispatcher function out of ftrace locations
2022-08-26 18:46 [PATCH bpf-next 0/2] bpf,ftrace: bpf dispatcher function fix Jiri Olsa
2022-08-26 18:46 ` [PATCH bpf-next 1/2] ftrace: Add HAVE_DYNAMIC_FTRACE_NO_PATCHABLE Jiri Olsa
@ 2022-08-26 18:46 ` Jiri Olsa
2022-08-28 23:01 ` KP Singh
2022-08-30 10:44 ` Peter Zijlstra
2022-08-29 22:25 ` [PATCH bpf-next 0/2] bpf,ftrace: bpf dispatcher function fix Daniel Borkmann
2 siblings, 2 replies; 11+ messages in thread
From: Jiri Olsa @ 2022-08-26 18:46 UTC (permalink / raw)
To: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko
Cc: Peter Zijlstra, bpf, Martin KaFai Lau, Song Liu, Yonghong Song,
John Fastabend, KP Singh, Stanislav Fomichev, Hao Luo,
Thomas Gleixner, Björn Töpel
The dispatcher function is attached/detached to trampoline by
dispatcher update function. At the same time it's available as
ftrace attachable function.
After discussion [1] the proposed solution is to use compiler
attributes to alter bpf_dispatcher_##name##_func function:
- remove it from being instrumented with __no_instrument_function__
attribute, so ftrace has no track of it
- but still generate 5 nop instructions with patchable_function_entry(5)
attribute, which are expected by bpf_arch_text_poke used by
dispatcher update function
Enabling HAVE_DYNAMIC_FTRACE_NO_PATCHABLE option for x86, so
__patchable_function_entries functions are not part of ftrace/mcount
locations.
The dispatcher code is generated and attached only for x86 so it's safe
to keep bpf_dispatcher func in patchable_function_entry locations for
other archs.
[1] https://lore.kernel.org/bpf/20220722110811.124515-1-jolsa@kernel.org/
Suggested-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
---
arch/x86/Kconfig | 1 +
include/linux/bpf.h | 2 ++
2 files changed, 3 insertions(+)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index f9920f1341c8..089c20cefd2b 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -284,6 +284,7 @@ config X86
select PROC_PID_ARCH_STATUS if PROC_FS
select HAVE_ARCH_NODE_DEV_GROUP if X86_SGX
imply IMA_SECURE_AND_OR_TRUSTED_BOOT if EFI
+ select HAVE_DYNAMIC_FTRACE_NO_PATCHABLE
config INSTRUCTION_DECODER
def_bool y
diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index 9c1674973e03..945d5414bb62 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -925,6 +925,8 @@ int arch_prepare_bpf_dispatcher(void *image, s64 *funcs, int num_funcs);
}
#define DEFINE_BPF_DISPATCHER(name) \
+ __attribute__((__no_instrument_function__)) \
+ __attribute__((patchable_function_entry(5))) \
noinline __nocfi unsigned int bpf_dispatcher_##name##_func( \
const void *ctx, \
const struct bpf_insn *insnsi, \
--
2.37.2
^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PATCH bpf-next 2/2] bpf: Move bpf_dispatcher function out of ftrace locations
2022-08-26 18:46 ` [PATCH bpf-next 2/2] bpf: Move bpf_dispatcher function out of ftrace locations Jiri Olsa
@ 2022-08-28 23:01 ` KP Singh
2022-08-30 10:44 ` Peter Zijlstra
1 sibling, 0 replies; 11+ messages in thread
From: KP Singh @ 2022-08-28 23:01 UTC (permalink / raw)
To: Jiri Olsa
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Peter Zijlstra, bpf, Martin KaFai Lau, Song Liu, Yonghong Song,
John Fastabend, Stanislav Fomichev, Hao Luo, Thomas Gleixner,
Björn Töpel
On Fri, Aug 26, 2022 at 8:46 PM Jiri Olsa <jolsa@kernel.org> wrote:
>
> The dispatcher function is attached/detached to trampoline by
> dispatcher update function. At the same time it's available as
> ftrace attachable function.
>
> After discussion [1] the proposed solution is to use compiler
> attributes to alter bpf_dispatcher_##name##_func function:
>
> - remove it from being instrumented with __no_instrument_function__
> attribute, so ftrace has no track of it
>
> - but still generate 5 nop instructions with patchable_function_entry(5)
> attribute, which are expected by bpf_arch_text_poke used by
> dispatcher update function
>
> Enabling HAVE_DYNAMIC_FTRACE_NO_PATCHABLE option for x86, so
> __patchable_function_entries functions are not part of ftrace/mcount
> locations.
>
> The dispatcher code is generated and attached only for x86 so it's safe
> to keep bpf_dispatcher func in patchable_function_entry locations for
> other archs.
>
> [1] https://lore.kernel.org/bpf/20220722110811.124515-1-jolsa@kernel.org/
> Suggested-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> Signed-off-by: Jiri Olsa <jolsa@kernel.org>
I read the whole discussion in
https://lore.kernel.org/bpf/CAADnVQLMY9Gbipx6Tc4dsRN3YSXo2CF8T=KwAvjU7nRDjYxRgQ@mail.gmail.com/
and this LGTM
Acked-by: KP Singh <kpsingh@kernel.org>
> ---
> arch/x86/Kconfig | 1 +
> include/linux/bpf.h | 2 ++
> 2 files changed, 3 insertions(+)
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index f9920f1341c8..089c20cefd2b 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -284,6 +284,7 @@ config X86
> select PROC_PID_ARCH_STATUS if PROC_FS
> select HAVE_ARCH_NODE_DEV_GROUP if X86_SGX
> imply IMA_SECURE_AND_OR_TRUSTED_BOOT if EFI
> + select HAVE_DYNAMIC_FTRACE_NO_PATCHABLE
>
> config INSTRUCTION_DECODER
> def_bool y
> diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> index 9c1674973e03..945d5414bb62 100644
> --- a/include/linux/bpf.h
> +++ b/include/linux/bpf.h
> @@ -925,6 +925,8 @@ int arch_prepare_bpf_dispatcher(void *image, s64 *funcs, int num_funcs);
> }
>
> #define DEFINE_BPF_DISPATCHER(name) \
> + __attribute__((__no_instrument_function__)) \
> + __attribute__((patchable_function_entry(5))) \
> noinline __nocfi unsigned int bpf_dispatcher_##name##_func( \
> const void *ctx, \
> const struct bpf_insn *insnsi, \
> --
> 2.37.2
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH bpf-next 0/2] bpf,ftrace: bpf dispatcher function fix
2022-08-26 18:46 [PATCH bpf-next 0/2] bpf,ftrace: bpf dispatcher function fix Jiri Olsa
2022-08-26 18:46 ` [PATCH bpf-next 1/2] ftrace: Add HAVE_DYNAMIC_FTRACE_NO_PATCHABLE Jiri Olsa
2022-08-26 18:46 ` [PATCH bpf-next 2/2] bpf: Move bpf_dispatcher function out of ftrace locations Jiri Olsa
@ 2022-08-29 22:25 ` Daniel Borkmann
2022-08-30 13:48 ` Jiri Olsa
2 siblings, 1 reply; 11+ messages in thread
From: Daniel Borkmann @ 2022-08-29 22:25 UTC (permalink / raw)
To: Jiri Olsa, Alexei Starovoitov, Andrii Nakryiko
Cc: bpf, Martin KaFai Lau, Song Liu, Yonghong Song, John Fastabend,
KP Singh, Stanislav Fomichev, Hao Luo, Peter Zijlstra,
Thomas Gleixner, Björn Töpel
On 8/26/22 8:46 PM, Jiri Olsa wrote:
> hi,
> as discussed [1] sending fix that moves bpf dispatcher function of out
> ftrace locations together with Peter's HAVE_DYNAMIC_FTRACE_NO_PATCHABLE
> dependency change.
Looks like the series breaks s390x builds; BPF CI link:
https://github.com/kernel-patches/bpf/runs/8079411784?check_suite_focus=true
[...]
CC net/xfrm/xfrm_state.o
CC net/packet/af_packet.o
{standard input}: Assembler messages:
{standard input}:16055: Error: bad expression
{standard input}:16056: Error: bad expression
{standard input}:16057: Error: bad expression
{standard input}:16058: Error: bad expression
{standard input}:16059: Error: bad expression
CC drivers/s390/char/raw3270.o
CC net/ipv6/ip6_output.o
[...]
CC net/xfrm/xfrm_output.o
CC net/ipv6/ip6_input.o
{standard input}:16055: Error: invalid operands (*ABS* and *UND* sections) for `%'
{standard input}:16056: Error: invalid operands (*ABS* and *UND* sections) for `%'
{standard input}:16057: Error: invalid operands (*ABS* and *UND* sections) for `%'
{standard input}:16058: Error: invalid operands (*ABS* and *UND* sections) for `%'
{standard input}:16059: Error: invalid operands (*ABS* and *UND* sections) for `%'
make[3]: *** [scripts/Makefile.build:249: net/core/filter.o] Error 1
make[2]: *** [scripts/Makefile.build:465: net/core] Error 2
make[2]: *** Waiting for unfinished jobs....
CC net/ipv4/tcp_fastopen.o
[...]
CC lib/percpu-refcount.o
make[1]: *** [Makefile:1855: net] Error 2
CC lib/rhashtable.o
make[1]: *** Waiting for unfinished jobs....
CC lib/base64.o
[...]
AR lib/built-in.a
CC kernel/kheaders.o
AR kernel/built-in.a
make: *** [Makefile:353: __build_one_by_one] Error 2
Error: Process completed with exit code 2.
> [1] https://lore.kernel.org/bpf/20220722110811.124515-1-jolsa@kernel.org/
> ---
> Jiri Olsa (1):
> bpf: Move bpf_dispatcher function out of ftrace locations
>
> Peter Zijlstra (Intel) (1):
> ftrace: Add HAVE_DYNAMIC_FTRACE_NO_PATCHABLE
>
> arch/x86/Kconfig | 1 +
> include/asm-generic/vmlinux.lds.h | 11 ++++++++++-
> include/linux/bpf.h | 2 ++
> kernel/trace/Kconfig | 6 ++++++
> tools/objtool/check.c | 3 ++-
> 5 files changed, 21 insertions(+), 2 deletions(-)
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH bpf-next 2/2] bpf: Move bpf_dispatcher function out of ftrace locations
2022-08-26 18:46 ` [PATCH bpf-next 2/2] bpf: Move bpf_dispatcher function out of ftrace locations Jiri Olsa
2022-08-28 23:01 ` KP Singh
@ 2022-08-30 10:44 ` Peter Zijlstra
2022-08-30 13:29 ` Jiri Olsa
1 sibling, 1 reply; 11+ messages in thread
From: Peter Zijlstra @ 2022-08-30 10:44 UTC (permalink / raw)
To: Jiri Olsa
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko, bpf,
Martin KaFai Lau, Song Liu, Yonghong Song, John Fastabend,
KP Singh, Stanislav Fomichev, Hao Luo, Thomas Gleixner,
Björn Töpel
On Fri, Aug 26, 2022 at 08:46:08PM +0200, Jiri Olsa wrote:
> The dispatcher function is attached/detached to trampoline by
> dispatcher update function. At the same time it's available as
> ftrace attachable function.
>
> After discussion [1] the proposed solution is to use compiler
> attributes to alter bpf_dispatcher_##name##_func function:
>
> - remove it from being instrumented with __no_instrument_function__
> attribute, so ftrace has no track of it
This is typically spelled like: 'notrace' in the kernel.
> - but still generate 5 nop instructions with patchable_function_entry(5)
> attribute, which are expected by bpf_arch_text_poke used by
> dispatcher update function
>
> Enabling HAVE_DYNAMIC_FTRACE_NO_PATCHABLE option for x86, so
> __patchable_function_entries functions are not part of ftrace/mcount
> locations.
>
> The dispatcher code is generated and attached only for x86 so it's safe
> to keep bpf_dispatcher func in patchable_function_entry locations for
> other archs.
>
> [1] https://lore.kernel.org/bpf/20220722110811.124515-1-jolsa@kernel.org/
> Suggested-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> Signed-off-by: Jiri Olsa <jolsa@kernel.org>
> ---
> arch/x86/Kconfig | 1 +
> include/linux/bpf.h | 2 ++
> 2 files changed, 3 insertions(+)
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index f9920f1341c8..089c20cefd2b 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -284,6 +284,7 @@ config X86
> select PROC_PID_ARCH_STATUS if PROC_FS
> select HAVE_ARCH_NODE_DEV_GROUP if X86_SGX
> imply IMA_SECURE_AND_OR_TRUSTED_BOOT if EFI
> + select HAVE_DYNAMIC_FTRACE_NO_PATCHABLE
>
> config INSTRUCTION_DECODER
> def_bool y
> diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> index 9c1674973e03..945d5414bb62 100644
> --- a/include/linux/bpf.h
> +++ b/include/linux/bpf.h
> @@ -925,6 +925,8 @@ int arch_prepare_bpf_dispatcher(void *image, s64 *funcs, int num_funcs);
> }
>
> #define DEFINE_BPF_DISPATCHER(name) \
> + __attribute__((__no_instrument_function__)) \
> + __attribute__((patchable_function_entry(5))) \
> noinline __nocfi unsigned int bpf_dispatcher_##name##_func( \
> const void *ctx, \
> const struct bpf_insn *insnsi, \
What makes that whole dispatcher thing x86 only? AFAICT it is only under
BPF_JIT here and could be used by anyone.
ARM64 for instance has BPG_JIT and builds net/core/filter.c. And ARM64
very much does use patchable_function_entry() for its ftrace
implementation.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH bpf-next 2/2] bpf: Move bpf_dispatcher function out of ftrace locations
2022-08-30 10:44 ` Peter Zijlstra
@ 2022-08-30 13:29 ` Jiri Olsa
0 siblings, 0 replies; 11+ messages in thread
From: Jiri Olsa @ 2022-08-30 13:29 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko, bpf,
Martin KaFai Lau, Song Liu, Yonghong Song, John Fastabend,
KP Singh, Stanislav Fomichev, Hao Luo, Thomas Gleixner,
Björn Töpel
On Tue, Aug 30, 2022 at 12:44:13PM +0200, Peter Zijlstra wrote:
> On Fri, Aug 26, 2022 at 08:46:08PM +0200, Jiri Olsa wrote:
> > The dispatcher function is attached/detached to trampoline by
> > dispatcher update function. At the same time it's available as
> > ftrace attachable function.
> >
> > After discussion [1] the proposed solution is to use compiler
> > attributes to alter bpf_dispatcher_##name##_func function:
> >
> > - remove it from being instrumented with __no_instrument_function__
> > attribute, so ftrace has no track of it
>
> This is typically spelled like: 'notrace' in the kernel.
>
> > - but still generate 5 nop instructions with patchable_function_entry(5)
> > attribute, which are expected by bpf_arch_text_poke used by
> > dispatcher update function
> >
> > Enabling HAVE_DYNAMIC_FTRACE_NO_PATCHABLE option for x86, so
> > __patchable_function_entries functions are not part of ftrace/mcount
> > locations.
> >
> > The dispatcher code is generated and attached only for x86 so it's safe
> > to keep bpf_dispatcher func in patchable_function_entry locations for
> > other archs.
> >
> > [1] https://lore.kernel.org/bpf/20220722110811.124515-1-jolsa@kernel.org/
> > Suggested-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> > Signed-off-by: Jiri Olsa <jolsa@kernel.org>
> > ---
> > arch/x86/Kconfig | 1 +
> > include/linux/bpf.h | 2 ++
> > 2 files changed, 3 insertions(+)
> >
> > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> > index f9920f1341c8..089c20cefd2b 100644
> > --- a/arch/x86/Kconfig
> > +++ b/arch/x86/Kconfig
> > @@ -284,6 +284,7 @@ config X86
> > select PROC_PID_ARCH_STATUS if PROC_FS
> > select HAVE_ARCH_NODE_DEV_GROUP if X86_SGX
> > imply IMA_SECURE_AND_OR_TRUSTED_BOOT if EFI
> > + select HAVE_DYNAMIC_FTRACE_NO_PATCHABLE
> >
> > config INSTRUCTION_DECODER
> > def_bool y
> > diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> > index 9c1674973e03..945d5414bb62 100644
> > --- a/include/linux/bpf.h
> > +++ b/include/linux/bpf.h
> > @@ -925,6 +925,8 @@ int arch_prepare_bpf_dispatcher(void *image, s64 *funcs, int num_funcs);
> > }
> >
> > #define DEFINE_BPF_DISPATCHER(name) \
> > + __attribute__((__no_instrument_function__)) \
> > + __attribute__((patchable_function_entry(5))) \
> > noinline __nocfi unsigned int bpf_dispatcher_##name##_func( \
> > const void *ctx, \
> > const struct bpf_insn *insnsi, \
>
> What makes that whole dispatcher thing x86 only? AFAICT it is only under
> BPF_JIT here and could be used by anyone.
it is just optimalization on x86, that transform default indirect calls to
direct call, described in changelog in here:
75ccbef6369e bpf: Introduce BPF dispatcher
other archs just make the call to bpf_func
jirka
>
> ARM64 for instance has BPG_JIT and builds net/core/filter.c. And ARM64
> very much does use patchable_function_entry() for its ftrace
> implementation.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH bpf-next 0/2] bpf,ftrace: bpf dispatcher function fix
2022-08-29 22:25 ` [PATCH bpf-next 0/2] bpf,ftrace: bpf dispatcher function fix Daniel Borkmann
@ 2022-08-30 13:48 ` Jiri Olsa
2022-08-30 16:46 ` Ilya Leoshkevich
0 siblings, 1 reply; 11+ messages in thread
From: Jiri Olsa @ 2022-08-30 13:48 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Alexei Starovoitov, Andrii Nakryiko, bpf, Martin KaFai Lau,
Song Liu, Yonghong Song, John Fastabend, KP Singh,
Stanislav Fomichev, Hao Luo, Peter Zijlstra, Thomas Gleixner,
Björn Töpel, Ilya Leoshkevich
On Tue, Aug 30, 2022 at 12:25:25AM +0200, Daniel Borkmann wrote:
> On 8/26/22 8:46 PM, Jiri Olsa wrote:
> > hi,
> > as discussed [1] sending fix that moves bpf dispatcher function of out
> > ftrace locations together with Peter's HAVE_DYNAMIC_FTRACE_NO_PATCHABLE
> > dependency change.
>
> Looks like the series breaks s390x builds; BPF CI link:
>
> https://github.com/kernel-patches/bpf/runs/8079411784?check_suite_focus=true
>
> [...]
> CC net/xfrm/xfrm_state.o
> CC net/packet/af_packet.o
> {standard input}: Assembler messages:
> {standard input}:16055: Error: bad expression
> {standard input}:16056: Error: bad expression
> {standard input}:16057: Error: bad expression
> {standard input}:16058: Error: bad expression
> {standard input}:16059: Error: bad expression
> CC drivers/s390/char/raw3270.o
> CC net/ipv6/ip6_output.o
> [...]
> CC net/xfrm/xfrm_output.o
> CC net/ipv6/ip6_input.o
> {standard input}:16055: Error: invalid operands (*ABS* and *UND* sections) for `%'
> {standard input}:16056: Error: invalid operands (*ABS* and *UND* sections) for `%'
> {standard input}:16057: Error: invalid operands (*ABS* and *UND* sections) for `%'
> {standard input}:16058: Error: invalid operands (*ABS* and *UND* sections) for `%'
> {standard input}:16059: Error: invalid operands (*ABS* and *UND* sections) for `%'
> make[3]: *** [scripts/Makefile.build:249: net/core/filter.o] Error 1
> make[2]: *** [scripts/Makefile.build:465: net/core] Error 2
> make[2]: *** Waiting for unfinished jobs....
> CC net/ipv4/tcp_fastopen.o
> [...]
> CC lib/percpu-refcount.o
> make[1]: *** [Makefile:1855: net] Error 2
> CC lib/rhashtable.o
> make[1]: *** Waiting for unfinished jobs....
> CC lib/base64.o
> [...]
> AR lib/built-in.a
> CC kernel/kheaders.o
> AR kernel/built-in.a
> make: *** [Makefile:353: __build_one_by_one] Error 2
> Error: Process completed with exit code 2.
it does not break on my cross build with gcc 12, but I can
reproduce with gcc 8 (CI seems to be on gcc 9)
the problem seems to be wrong assembler code with extra '%'
that's generated for patchable_function_entry(5)
gcc 8 generates:
.LPFE1:
nopr %%r0
nopr %%r0
nopr %%r0
nopr %%r0
nopr %%r0
and gcc 12 generates:
.LPFE1:
nopr %r0
nopr %r0
nopr %r0
nopr %r0
nopr %r0
perhaps we need to upgrade gcc in CI? cc-ing Ilya, any idea?
thanks,
jirka
>
> > [1] https://lore.kernel.org/bpf/20220722110811.124515-1-jolsa@kernel.org/
> > ---
> > Jiri Olsa (1):
> > bpf: Move bpf_dispatcher function out of ftrace locations
> >
> > Peter Zijlstra (Intel) (1):
> > ftrace: Add HAVE_DYNAMIC_FTRACE_NO_PATCHABLE
> >
> > arch/x86/Kconfig | 1 +
> > include/asm-generic/vmlinux.lds.h | 11 ++++++++++-
> > include/linux/bpf.h | 2 ++
> > kernel/trace/Kconfig | 6 ++++++
> > tools/objtool/check.c | 3 ++-
> > 5 files changed, 21 insertions(+), 2 deletions(-)
> >
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH bpf-next 0/2] bpf,ftrace: bpf dispatcher function fix
2022-08-30 13:48 ` Jiri Olsa
@ 2022-08-30 16:46 ` Ilya Leoshkevich
2022-08-30 23:46 ` Ilya Leoshkevich
0 siblings, 1 reply; 11+ messages in thread
From: Ilya Leoshkevich @ 2022-08-30 16:46 UTC (permalink / raw)
To: Jiri Olsa, Daniel Borkmann
Cc: Alexei Starovoitov, Andrii Nakryiko, bpf, Martin KaFai Lau,
Song Liu, Yonghong Song, John Fastabend, KP Singh,
Stanislav Fomichev, Hao Luo, Peter Zijlstra, Thomas Gleixner,
Björn Töpel
On Tue, 2022-08-30 at 15:48 +0200, Jiri Olsa wrote:
> On Tue, Aug 30, 2022 at 12:25:25AM +0200, Daniel Borkmann wrote:
> > On 8/26/22 8:46 PM, Jiri Olsa wrote:
> > > hi,
> > > as discussed [1] sending fix that moves bpf dispatcher function
> > > of out
> > > ftrace locations together with Peter's
> > > HAVE_DYNAMIC_FTRACE_NO_PATCHABLE
> > > dependency change.
> >
> > Looks like the series breaks s390x builds; BPF CI link:
> >
> > https://github.com/kernel-patches/bpf/runs/8079411784?check_suite_focus=true
> >
> > [...]
> > CC net/xfrm/xfrm_state.o
> > CC net/packet/af_packet.o
> > {standard input}: Assembler messages:
> > {standard input}:16055: Error: bad expression
> > {standard input}:16056: Error: bad expression
> > {standard input}:16057: Error: bad expression
> > {standard input}:16058: Error: bad expression
> > {standard input}:16059: Error: bad expression
> > CC drivers/s390/char/raw3270.o
> > CC net/ipv6/ip6_output.o
> > [...]
> > CC net/xfrm/xfrm_output.o
> > CC net/ipv6/ip6_input.o
> > {standard input}:16055: Error: invalid operands (*ABS* and *UND*
> > sections) for `%'
> > {standard input}:16056: Error: invalid operands (*ABS* and *UND*
> > sections) for `%'
> > {standard input}:16057: Error: invalid operands (*ABS* and *UND*
> > sections) for `%'
> > {standard input}:16058: Error: invalid operands (*ABS* and *UND*
> > sections) for `%'
> > {standard input}:16059: Error: invalid operands (*ABS* and *UND*
> > sections) for `%'
> > make[3]: *** [scripts/Makefile.build:249: net/core/filter.o]
> > Error 1
> > make[2]: *** [scripts/Makefile.build:465: net/core] Error 2
> > make[2]: *** Waiting for unfinished jobs....
> > CC net/ipv4/tcp_fastopen.o
> > [...]
> > CC lib/percpu-refcount.o
> > make[1]: *** [Makefile:1855: net] Error 2
> > CC lib/rhashtable.o
> > make[1]: *** Waiting for unfinished jobs....
> > CC lib/base64.o
> > [...]
> > AR lib/built-in.a
> > CC kernel/kheaders.o
> > AR kernel/built-in.a
> > make: *** [Makefile:353: __build_one_by_one] Error 2
> > Error: Process completed with exit code 2.
>
>
> it does not break on my cross build with gcc 12, but I can
> reproduce with gcc 8 (CI seems to be on gcc 9)
>
> the problem seems to be wrong assembler code with extra '%'
> that's generated for patchable_function_entry(5)
>
> gcc 8 generates:
>
> .LPFE1:
> nopr %%r0
> nopr %%r0
> nopr %%r0
> nopr %%r0
> nopr %%r0
>
> and gcc 12 generates:
>
> .LPFE1:
> nopr %r0
> nopr %r0
> nopr %r0
> nopr %r0
> nopr %r0
>
> perhaps we need to upgrade gcc in CI? cc-ing Ilya, any idea?
>
> thanks,
> jirka
It's not obvious to me which gcc commit fixed this; I will bisect and
find out. This will take some time.
However, officially, the kernel must be buildable by gcc 5.1+.
Whatever I find, it's unlikely that we'll be able to backport it
that far.
Therefore I think we need to find a way to conditionally
do something else when using broken gccs. Or maybe just keep this
x86-only after all.
Best regards,
Ilya
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH bpf-next 0/2] bpf,ftrace: bpf dispatcher function fix
2022-08-30 16:46 ` Ilya Leoshkevich
@ 2022-08-30 23:46 ` Ilya Leoshkevich
2022-08-31 10:00 ` Jiri Olsa
0 siblings, 1 reply; 11+ messages in thread
From: Ilya Leoshkevich @ 2022-08-30 23:46 UTC (permalink / raw)
To: Jiri Olsa, Daniel Borkmann
Cc: Alexei Starovoitov, Andrii Nakryiko, bpf, Martin KaFai Lau,
Song Liu, Yonghong Song, John Fastabend, KP Singh,
Stanislav Fomichev, Hao Luo, Peter Zijlstra, Thomas Gleixner,
Björn Töpel
On Tue, 2022-08-30 at 18:46 +0200, Ilya Leoshkevich wrote:
> On Tue, 2022-08-30 at 15:48 +0200, Jiri Olsa wrote:
> > On Tue, Aug 30, 2022 at 12:25:25AM +0200, Daniel Borkmann wrote:
> > > On 8/26/22 8:46 PM, Jiri Olsa wrote:
> > > > hi,
> > > > as discussed [1] sending fix that moves bpf dispatcher function
> > > > of out
> > > > ftrace locations together with Peter's
> > > > HAVE_DYNAMIC_FTRACE_NO_PATCHABLE
> > > > dependency change.
> > >
> > > Looks like the series breaks s390x builds; BPF CI link:
> > >
> > > https://github.com/kernel-patches/bpf/runs/8079411784?check_suite_focus=true
> > >
> > > [...]
> > > CC net/xfrm/xfrm_state.o
> > > CC net/packet/af_packet.o
> > > {standard input}: Assembler messages:
> > > {standard input}:16055: Error: bad expression
> > > {standard input}:16056: Error: bad expression
> > > {standard input}:16057: Error: bad expression
> > > {standard input}:16058: Error: bad expression
> > > {standard input}:16059: Error: bad expression
> > > CC drivers/s390/char/raw3270.o
> > > CC net/ipv6/ip6_output.o
> > > [...]
> > > CC net/xfrm/xfrm_output.o
> > > CC net/ipv6/ip6_input.o
> > > {standard input}:16055: Error: invalid operands (*ABS* and
> > > *UND*
> > > sections) for `%'
> > > {standard input}:16056: Error: invalid operands (*ABS* and
> > > *UND*
> > > sections) for `%'
> > > {standard input}:16057: Error: invalid operands (*ABS* and
> > > *UND*
> > > sections) for `%'
> > > {standard input}:16058: Error: invalid operands (*ABS* and
> > > *UND*
> > > sections) for `%'
> > > {standard input}:16059: Error: invalid operands (*ABS* and
> > > *UND*
> > > sections) for `%'
> > > make[3]: *** [scripts/Makefile.build:249: net/core/filter.o]
> > > Error 1
> > > make[2]: *** [scripts/Makefile.build:465: net/core] Error 2
> > > make[2]: *** Waiting for unfinished jobs....
> > > CC net/ipv4/tcp_fastopen.o
> > > [...]
> > > CC lib/percpu-refcount.o
> > > make[1]: *** [Makefile:1855: net] Error 2
> > > CC lib/rhashtable.o
> > > make[1]: *** Waiting for unfinished jobs....
> > > CC lib/base64.o
> > > [...]
> > > AR lib/built-in.a
> > > CC kernel/kheaders.o
> > > AR kernel/built-in.a
> > > make: *** [Makefile:353: __build_one_by_one] Error 2
> > > Error: Process completed with exit code 2.
> >
> >
> > it does not break on my cross build with gcc 12, but I can
> > reproduce with gcc 8 (CI seems to be on gcc 9)
> >
> > the problem seems to be wrong assembler code with extra '%'
> > that's generated for patchable_function_entry(5)
> >
> > gcc 8 generates:
> >
> > .LPFE1:
> > nopr %%r0
> > nopr %%r0
> > nopr %%r0
> > nopr %%r0
> > nopr %%r0
> >
> > and gcc 12 generates:
> >
> > .LPFE1:
> > nopr %r0
> > nopr %r0
> > nopr %r0
> > nopr %r0
> > nopr %r0
> >
> > perhaps we need to upgrade gcc in CI? cc-ing Ilya, any idea?
> >
> > thanks,
> > jirka
>
> It's not obvious to me which gcc commit fixed this; I will bisect and
> find out. This will take some time.
>
> However, officially, the kernel must be buildable by gcc 5.1+.
> Whatever I find, it's unlikely that we'll be able to backport it
> that far.
>
> Therefore I think we need to find a way to conditionally
> do something else when using broken gccs. Or maybe just keep this
> x86-only after all.
>
> Best regards,
> Ilya
FWIW, bisect points to
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=45d06a4045bebc3dbaaf0b1c676f4e22b7c6aca1
which makes perfect sense. Still, as I mentioned above, it's probably
worth tolerating brokens gccs instead of spending time backporting this
everywhere. And upgrading the CI machine will only paper over the
issue.
At a closer look, it looks weird to me that we have
patchable_function_entry(5) in a common header. If this optimization
is ever implemented for another architecture, a different number will
be required.
For simplicity, would it make sense to hide this under an #ifdef?
Something like this (untested):
#ifdef CONFIG_X86
#define BPF_DISPATCHER_ATTRIBUTES
__attribute__((patchable_function_entry(5)))
#else
#define BPF_DISPATCHER_ATTRIBUTES
#endif
Best regards,
Ilya
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH bpf-next 0/2] bpf,ftrace: bpf dispatcher function fix
2022-08-30 23:46 ` Ilya Leoshkevich
@ 2022-08-31 10:00 ` Jiri Olsa
0 siblings, 0 replies; 11+ messages in thread
From: Jiri Olsa @ 2022-08-31 10:00 UTC (permalink / raw)
To: Ilya Leoshkevich
Cc: Jiri Olsa, Daniel Borkmann, Alexei Starovoitov, Andrii Nakryiko,
bpf, Martin KaFai Lau, Song Liu, Yonghong Song, John Fastabend,
KP Singh, Stanislav Fomichev, Hao Luo, Peter Zijlstra,
Thomas Gleixner, Björn Töpel
On Wed, Aug 31, 2022 at 01:46:09AM +0200, Ilya Leoshkevich wrote:
> On Tue, 2022-08-30 at 18:46 +0200, Ilya Leoshkevich wrote:
> > On Tue, 2022-08-30 at 15:48 +0200, Jiri Olsa wrote:
> > > On Tue, Aug 30, 2022 at 12:25:25AM +0200, Daniel Borkmann wrote:
> > > > On 8/26/22 8:46 PM, Jiri Olsa wrote:
> > > > > hi,
> > > > > as discussed [1] sending fix that moves bpf dispatcher function
> > > > > of out
> > > > > ftrace locations together with Peter's
> > > > > HAVE_DYNAMIC_FTRACE_NO_PATCHABLE
> > > > > dependency change.
> > > >
> > > > Looks like the series breaks s390x builds; BPF CI link:
> > > >
> > > > https://github.com/kernel-patches/bpf/runs/8079411784?check_suite_focus=true
> > > >
> > > > [...]
> > > > CC net/xfrm/xfrm_state.o
> > > > CC net/packet/af_packet.o
> > > > {standard input}: Assembler messages:
> > > > {standard input}:16055: Error: bad expression
> > > > {standard input}:16056: Error: bad expression
> > > > {standard input}:16057: Error: bad expression
> > > > {standard input}:16058: Error: bad expression
> > > > {standard input}:16059: Error: bad expression
> > > > CC drivers/s390/char/raw3270.o
> > > > CC net/ipv6/ip6_output.o
> > > > [...]
> > > > CC net/xfrm/xfrm_output.o
> > > > CC net/ipv6/ip6_input.o
> > > > {standard input}:16055: Error: invalid operands (*ABS* and
> > > > *UND*
> > > > sections) for `%'
> > > > {standard input}:16056: Error: invalid operands (*ABS* and
> > > > *UND*
> > > > sections) for `%'
> > > > {standard input}:16057: Error: invalid operands (*ABS* and
> > > > *UND*
> > > > sections) for `%'
> > > > {standard input}:16058: Error: invalid operands (*ABS* and
> > > > *UND*
> > > > sections) for `%'
> > > > {standard input}:16059: Error: invalid operands (*ABS* and
> > > > *UND*
> > > > sections) for `%'
> > > > make[3]: *** [scripts/Makefile.build:249: net/core/filter.o]
> > > > Error 1
> > > > make[2]: *** [scripts/Makefile.build:465: net/core] Error 2
> > > > make[2]: *** Waiting for unfinished jobs....
> > > > CC net/ipv4/tcp_fastopen.o
> > > > [...]
> > > > CC lib/percpu-refcount.o
> > > > make[1]: *** [Makefile:1855: net] Error 2
> > > > CC lib/rhashtable.o
> > > > make[1]: *** Waiting for unfinished jobs....
> > > > CC lib/base64.o
> > > > [...]
> > > > AR lib/built-in.a
> > > > CC kernel/kheaders.o
> > > > AR kernel/built-in.a
> > > > make: *** [Makefile:353: __build_one_by_one] Error 2
> > > > Error: Process completed with exit code 2.
> > >
> > >
> > > it does not break on my cross build with gcc 12, but I can
> > > reproduce with gcc 8 (CI seems to be on gcc 9)
> > >
> > > the problem seems to be wrong assembler code with extra '%'
> > > that's generated for patchable_function_entry(5)
> > >
> > > gcc 8 generates:
> > >
> > > .LPFE1:
> > > nopr %%r0
> > > nopr %%r0
> > > nopr %%r0
> > > nopr %%r0
> > > nopr %%r0
> > >
> > > and gcc 12 generates:
> > >
> > > .LPFE1:
> > > nopr %r0
> > > nopr %r0
> > > nopr %r0
> > > nopr %r0
> > > nopr %r0
> > >
> > > perhaps we need to upgrade gcc in CI? cc-ing Ilya, any idea?
> > >
> > > thanks,
> > > jirka
> >
> > It's not obvious to me which gcc commit fixed this; I will bisect and
> > find out. This will take some time.
> >
> > However, officially, the kernel must be buildable by gcc 5.1+.
> > Whatever I find, it's unlikely that we'll be able to backport it
> > that far.
> >
> > Therefore I think we need to find a way to conditionally
> > do something else when using broken gccs. Or maybe just keep this
> > x86-only after all.
> >
> > Best regards,
> > Ilya
>
> FWIW, bisect points to
>
> https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=45d06a4045bebc3dbaaf0b1c676f4e22b7c6aca1
great, thanks for doing that
>
> which makes perfect sense. Still, as I mentioned above, it's probably
> worth tolerating brokens gccs instead of spending time backporting this
> everywhere. And upgrading the CI machine will only paper over the
> issue.
>
> At a closer look, it looks weird to me that we have
> patchable_function_entry(5) in a common header. If this optimization
> is ever implemented for another architecture, a different number will
> be required.
>
> For simplicity, would it make sense to hide this under an #ifdef?
> Something like this (untested):
>
> #ifdef CONFIG_X86
> #define BPF_DISPATCHER_ATTRIBUTES
> __attribute__((patchable_function_entry(5)))
> #else
> #define BPF_DISPATCHER_ATTRIBUTES
> #endif
right, I think we can limit it directly to x86_64 like below
jirka
---
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index f9920f1341c8..089c20cefd2b 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -284,6 +284,7 @@ config X86
select PROC_PID_ARCH_STATUS if PROC_FS
select HAVE_ARCH_NODE_DEV_GROUP if X86_SGX
imply IMA_SECURE_AND_OR_TRUSTED_BOOT if EFI
+ select HAVE_DYNAMIC_FTRACE_NO_PATCHABLE
config INSTRUCTION_DECODER
def_bool y
diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index 9c1674973e03..4ab4b0a1beb8 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -924,7 +924,15 @@ int arch_prepare_bpf_dispatcher(void *image, s64 *funcs, int num_funcs);
}, \
}
+#ifdef CONFIG_X86_64
+#define BPF_DISPATCHER_ATTRIBUTES __attribute__((__no_instrument_function__)) \
+ __attribute__((patchable_function_entry(5)))
+#else
+#define BPF_DISPATCHER_ATTRIBUTES
+#endif
+
#define DEFINE_BPF_DISPATCHER(name) \
+ BPF_DISPATCHER_ATTRIBUTES \
noinline __nocfi unsigned int bpf_dispatcher_##name##_func( \
const void *ctx, \
const struct bpf_insn *insnsi, \
^ permalink raw reply related [flat|nested] 11+ messages in thread
end of thread, other threads:[~2022-08-31 10:01 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-08-26 18:46 [PATCH bpf-next 0/2] bpf,ftrace: bpf dispatcher function fix Jiri Olsa
2022-08-26 18:46 ` [PATCH bpf-next 1/2] ftrace: Add HAVE_DYNAMIC_FTRACE_NO_PATCHABLE Jiri Olsa
2022-08-26 18:46 ` [PATCH bpf-next 2/2] bpf: Move bpf_dispatcher function out of ftrace locations Jiri Olsa
2022-08-28 23:01 ` KP Singh
2022-08-30 10:44 ` Peter Zijlstra
2022-08-30 13:29 ` Jiri Olsa
2022-08-29 22:25 ` [PATCH bpf-next 0/2] bpf,ftrace: bpf dispatcher function fix Daniel Borkmann
2022-08-30 13:48 ` Jiri Olsa
2022-08-30 16:46 ` Ilya Leoshkevich
2022-08-30 23:46 ` Ilya Leoshkevich
2022-08-31 10:00 ` Jiri Olsa
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox