From: Jiri Olsa <hidden> Date: 2021-07-07 21:48:23
hi,
adding bpf_get_func_ip helper that returns IP address of the
caller function for trampoline and krobe programs.
There're 2 specific implementation of the bpf_get_func_ip
helper, one for trampoline progs and one for kprobe/kretprobe
progs.
The trampoline helper call is replaced/inlined by verifier
with simple move instruction. The kprobe/kretprobe is actual
helper call that returns prepared caller address.
Also available at:
https://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git
bpf/get_func_ip
v3 changes:
- resend with Masami in cc and v3 in each patch subject
v2 changes:
- use kprobe_running to get kprobe instead of cpu var [Masami]
- added support to add kprobe on function+offset
and test for that [Alan]
thanks,
jirka
---
Alan Maguire (1):
libbpf: allow specification of "kprobe/function+offset"
Jiri Olsa (6):
bpf, x86: Store caller's ip in trampoline stack
bpf: Enable BPF_TRAMP_F_IP_ARG for trampolines with call_get_func_ip
bpf: Add bpf_get_func_ip helper for tracing programs
bpf: Add bpf_get_func_ip helper for kprobe programs
selftests/bpf: Add test for bpf_get_func_ip helper
selftests/bpf: Add test for bpf_get_func_ip in kprobe+offset probe
arch/x86/net/bpf_jit_comp.c | 19 +++++++++++++++++++
include/linux/bpf.h | 5 +++++
include/linux/filter.h | 3 ++-
include/uapi/linux/bpf.h | 7 +++++++
kernel/bpf/trampoline.c | 12 +++++++++---
kernel/bpf/verifier.c | 55 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
kernel/trace/bpf_trace.c | 32 ++++++++++++++++++++++++++++++++
tools/include/uapi/linux/bpf.h | 7 +++++++
tools/lib/bpf/libbpf.c | 20 +++++++++++++++++---
tools/testing/selftests/bpf/prog_tests/get_func_ip_test.c | 42 ++++++++++++++++++++++++++++++++++++++++++
tools/testing/selftests/bpf/progs/get_func_ip_test.c | 75 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
11 files changed, 270 insertions(+), 7 deletions(-)
create mode 100644 tools/testing/selftests/bpf/prog_tests/get_func_ip_test.c
create mode 100644 tools/testing/selftests/bpf/progs/get_func_ip_test.c
From: Jiri Olsa <hidden> Date: 2021-07-07 21:48:13
Storing caller's ip in trampoline's stack. Trampoline programs
can reach the IP in (ctx - 8) address, so there's no change in
program's arguments interface.
The IP address is takes from [fp + 8], which is return address
from the initial 'call fentry' call to trampoline.
This IP address will be returned via bpf_get_func_ip helper
helper, which is added in following patches.
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
---
arch/x86/net/bpf_jit_comp.c | 19 +++++++++++++++++++
include/linux/bpf.h | 5 +++++
2 files changed, 24 insertions(+)
@@ -1951,6 +1951,9 @@ int arch_prepare_bpf_trampoline(struct bpf_tramp_image *im, void *image, void *iif(flags&BPF_TRAMP_F_CALL_ORIG)stack_size+=8;/* room for return value of orig_call */+if(flags&BPF_TRAMP_F_IP_ARG)+stack_size+=8;/* room for IP address argument */+if(flags&BPF_TRAMP_F_SKIP_FRAME)/* skip patched call instruction and point orig_call to actual*bodyofthekernelfunction.
@@ -1964,6 +1967,22 @@ int arch_prepare_bpf_trampoline(struct bpf_tramp_image *im, void *image, void *iEMIT4(0x48,0x83,0xEC,stack_size);/* sub rsp, stack_size */EMIT1(0x53);/* push rbx */+if(flags&BPF_TRAMP_F_IP_ARG){+/* Store IP address of the traced function:+*movrax,QWORDPTR[rbp+8]+*subrax,X86_PATCH_SIZE+*movQWORDPTR[rbp-stack_size],rax+*/+emit_ldx(&prog,BPF_DW,BPF_REG_0,BPF_REG_FP,8);+EMIT4(0x48,0x83,0xe8,X86_PATCH_SIZE);+emit_stx(&prog,BPF_DW,BPF_REG_FP,BPF_REG_0,-stack_size);++/* Continue with stack_size for regs storage, stack will+*becorrectlyrestoredwith'leave'instruction.+*/+stack_size-=8;+}+save_regs(m,&prog,nr_args,stack_size);if(flags&BPF_TRAMP_F_CALL_ORIG){
@@ -554,6 +554,11 @@ struct btf_func_model {*/#define BPF_TRAMP_F_SKIP_FRAME BIT(2)+/* Store IP address of the caller on the trampoline stack,+*soit'savailablefortrampoline'sprograms.+*/+#define BPF_TRAMP_F_IP_ARG BIT(3)+/* Each call __bpf_prog_enter + call bpf_func + call __bpf_prog_exit is ~50*bytesonx86.PickanumbertofitintoBPF_IMAGE_SIZE/2*/
From: Jiri Olsa <hidden> Date: 2021-07-07 21:48:21
Enabling BPF_TRAMP_F_IP_ARG for trampolines that actually need it.
The BPF_TRAMP_F_IP_ARG adds extra 3 instructions to trampoline code
and is used only by programs with bpf_get_func_ip helper, which is
added in following patch and sets call_get_func_ip bit.
This patch ensures that BPF_TRAMP_F_IP_ARG flag is used only for
trampolines that have programs with call_get_func_ip set.
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
---
include/linux/filter.h | 3 ++-
kernel/bpf/trampoline.c | 12 +++++++++---
2 files changed, 11 insertions(+), 4 deletions(-)
@@ -559,7 +559,8 @@ struct bpf_prog {kprobe_override:1,/* Do we override a kprobe? */has_callchain_buf:1,/* callchain buffer allocated? */enforce_expected_attach_type:1,/* Enforce expected_attach_type checking at attach time */-call_get_stack:1;/* Do we call bpf_get_stack() or bpf_get_stackid() */+call_get_stack:1,/* Do we call bpf_get_stack() or bpf_get_stackid() */+call_get_func_ip:1;/* Do we call get_func_ip() */enumbpf_prog_typetype;/* Type of BPF program */enumbpf_attach_typeexpected_attach_type;/* For some prog types */u32len;/* Number of filter blocks */
From: Jiri Olsa <hidden> Date: 2021-07-07 21:48:36
Adding bpf_get_func_ip helper for BPF_PROG_TYPE_TRACING programs,
specifically for all trampoline attach types.
The trampoline's caller IP address is stored in (ctx - 8) address.
so there's no reason to actually call the helper, but rather fixup
the call instruction and return [ctx - 8] value directly (suggested
by Alexei).
[fixed has_get_func_ip wrong return type]
Reported-by: kernel test robot <redacted>
Reported-by: Dan Carpenter <redacted>
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
---
include/uapi/linux/bpf.h | 7 +++++
kernel/bpf/verifier.c | 53 ++++++++++++++++++++++++++++++++++
kernel/trace/bpf_trace.c | 15 ++++++++++
tools/include/uapi/linux/bpf.h | 7 +++++
4 files changed, 82 insertions(+)
@@ -4780,6 +4780,12 @@ union bpf_attr {*ExecuteclosesyscallforgivenFD.*Return*Asyscallresult.+*+*u64bpf_get_func_ip(void*ctx)+*Description+*Getaddressofthetracedfunction(fortracingprograms).+*Return+*Addressofthetracedfunction.*/#define __BPF_FUNC_MAPPER(FN) \FN(unspec),\
@@ -4951,6 +4957,7 @@ union bpf_attr {FN(sys_bpf),\FN(btf_find_by_name_kind),\FN(sys_close),\+FN(get_func_ip),\/* *//* integer value in 'imm' field of BPF_CALL instruction selects which helper
@@ -5955,6 +5960,32 @@ static int check_bpf_snprintf_call(struct bpf_verifier_env *env,returnerr;}+staticinthas_get_func_ip(structbpf_verifier_env*env)+{+enumbpf_attach_typeeatype=env->prog->expected_attach_type;+enumbpf_prog_typetype=resolve_prog_type(env->prog);+intfunc_id=BPF_FUNC_get_func_ip;++if(type==BPF_PROG_TYPE_TRACING){+if(eatype!=BPF_TRACE_FENTRY&&eatype!=BPF_TRACE_FEXIT&&+eatype!=BPF_MODIFY_RETURN){+verbose(env,"func %s#%d supported only for fentry/fexit/fmod_ret programs\n",+func_id_name(func_id),func_id);+return-ENOTSUPP;+}+if(!allow_get_func_ip_tracing(env)){+verbose(env,"func %s#%d for tracing programs supported only for JITed x86_64\n",+func_id_name(func_id),func_id);+return-ENOTSUPP;+}+return0;+}++verbose(env,"func %s#%d not supported for program type %d\n",+func_id_name(func_id),func_id,type);+return-ENOTSUPP;+}+staticintcheck_helper_call(structbpf_verifier_env*env,structbpf_insn*insn,int*insn_idx_p){
@@ -12369,6 +12406,7 @@ static int do_misc_fixups(struct bpf_verifier_env *env){structbpf_prog*prog=env->prog;boolexpect_blinding=bpf_jit_blinding_enabled(prog);+enumbpf_prog_typeprog_type=resolve_prog_type(prog);structbpf_insn*insn=prog->insnsi;conststructbpf_func_proto*fn;constintinsn_cnt=prog->len;
@@ -12702,6 +12740,21 @@ static int do_misc_fixups(struct bpf_verifier_env *env)continue;}+/* Implement bpf_get_func_ip inline. */+if(prog_type==BPF_PROG_TYPE_TRACING&&+insn->imm==BPF_FUNC_get_func_ip){+/* Load IP address from ctx - 8 */+insn_buf[0]=BPF_LDX_MEM(BPF_DW,BPF_REG_0,BPF_REG_1,-8);++new_prog=bpf_patch_insn_data(env,i+delta,insn_buf,1);+if(!new_prog)+return-ENOMEM;++env->prog=prog=new_prog;+insn=new_prog->insnsi+i+delta;+continue;+}+patch_call_imm:fn=env->ops->get_func_proto(insn->imm,env->prog);/* all functions that have prototype and verifier allowed
@@ -948,6 +948,19 @@ const struct bpf_func_proto bpf_snprintf_btf_proto = {.arg5_type=ARG_ANYTHING,};+BPF_CALL_1(bpf_get_func_ip_tracing,void*,ctx)+{+/* Stub, the helper call is inlined in the program. */+return0;+}++staticconststructbpf_func_protobpf_get_func_ip_proto_tracing={+.func=bpf_get_func_ip_tracing,+.gpl_only=true,+.ret_type=RET_INTEGER,+.arg1_type=ARG_PTR_TO_CTX,+};+conststructbpf_func_proto*bpf_tracing_func_proto(enumbpf_func_idfunc_id,conststructbpf_prog*prog){
@@ -4780,6 +4780,12 @@ union bpf_attr {*ExecuteclosesyscallforgivenFD.*Return*Asyscallresult.+*+*u64bpf_get_func_ip(void*ctx)+*Description+*Getaddressofthetracedfunction(fortracingprograms).+*Return+*Addressofthetracedfunction.*/#define __BPF_FUNC_MAPPER(FN) \FN(unspec),\
@@ -4951,6 +4957,7 @@ union bpf_attr {FN(sys_bpf),\FN(btf_find_by_name_kind),\FN(sys_close),\+FN(get_func_ip),\/* *//* integer value in 'imm' field of BPF_CALL instruction selects which helper
From: Jiri Olsa <hidden> Date: 2021-07-07 21:48:40
Adding bpf_get_func_ip helper for BPF_PROG_TYPE_KPROBE programs,
so it's now possible to call bpf_get_func_ip from both kprobe and
kretprobe programs.
Taking the caller's address from 'struct kprobe::addr', which is
defined for both kprobe and kretprobe.
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
---
include/uapi/linux/bpf.h | 2 +-
kernel/bpf/verifier.c | 2 ++
kernel/trace/bpf_trace.c | 17 +++++++++++++++++
tools/include/uapi/linux/bpf.h | 2 +-
4 files changed, 21 insertions(+), 2 deletions(-)
@@ -5979,6 +5979,8 @@ static int has_get_func_ip(struct bpf_verifier_env *env)return-ENOTSUPP;}return0;+}elseif(type==BPF_PROG_TYPE_KPROBE){+return0;}verbose(env,"func %s#%d not supported for program type %d\n",
From: Jiri Olsa <hidden> Date: 2021-07-07 21:49:04
From: Alan Maguire <redacted>
kprobes can be placed on most instructions in a function, not
just entry, and ftrace and bpftrace support the function+offset
notification for probe placement. Adding parsing of func_name
into func+offset to bpf_program__attach_kprobe() allows the
user to specify
SEC("kprobe/bpf_fentry_test5+0x6")
...for example, and the offset can be passed to perf_event_open_probe()
to support kprobe attachment.
Signed-off-by: Alan Maguire <redacted>
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
---
tools/lib/bpf/libbpf.c | 20 +++++++++++++++++---
1 file changed, 17 insertions(+), 3 deletions(-)
From: Jiri Olsa <hidden> Date: 2021-07-07 21:49:16
Adding test for bpf_get_func_ip in kprobe+ofset probe.
Because of the offset value it's arch specific, adding
it only for x86_64 architecture.
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
---
.../testing/selftests/bpf/progs/get_func_ip_test.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
@@ -60,3 +61,15 @@ int BPF_PROG(fmod_ret_test, int a, int *b, int ret)test5_result=(constvoid*)addr==&bpf_modify_return_test;returnret;}++#ifdef __x86_64__+__u64test6_result=0;+SEC("kprobe/bpf_fentry_test6+0x5")+inttest6(structpt_regs*ctx)+{+__u64addr=bpf_get_func_ip(ctx);++test6_result=(constvoid*)addr==&bpf_fentry_test6+5;+return0;+}+#endif
On Wed, Jul 7, 2021 at 2:53 PM Jiri Olsa [off-list ref] wrote:
Adding bpf_get_func_ip helper for BPF_PROG_TYPE_TRACING programs,
specifically for all trampoline attach types.
The trampoline's caller IP address is stored in (ctx - 8) address.
so there's no reason to actually call the helper, but rather fixup
the call instruction and return [ctx - 8] value directly (suggested
by Alexei).
[fixed has_get_func_ip wrong return type]
Reported-by: kernel test robot <redacted>
Reported-by: Dan Carpenter <redacted>
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
---
include/uapi/linux/bpf.h | 7 +++++
kernel/bpf/verifier.c | 53 ++++++++++++++++++++++++++++++++++
kernel/trace/bpf_trace.c | 15 ++++++++++
tools/include/uapi/linux/bpf.h | 7 +++++
4 files changed, 82 insertions(+)
[...]
quoted hunk
static int check_helper_call(struct bpf_verifier_env *env, struct bpf_insn *insn,
int *insn_idx_p)
{
@@ -6225,6 +6256,12 @@ static int check_helper_call(struct bpf_verifier_env *env, struct bpf_insn *insn if (func_id == BPF_FUNC_get_stackid || func_id == BPF_FUNC_get_stack) env->prog->call_get_stack = true;+ if (func_id == BPF_FUNC_get_func_ip) {+ if (has_get_func_ip(env))
from has_xxx name I'd expect it returns true/false, so this reads
super confusing. check_get_func_ip would be a bit more consistent with
other cases like this (still reads confusing to me, but that's ok)
On Wed, Jul 7, 2021 at 2:54 PM Jiri Olsa [off-list ref] wrote:
Adding test for bpf_get_func_ip helper for fentry, fexit,
kprobe, kretprobe and fmod_ret programs.
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
---
.../bpf/prog_tests/get_func_ip_test.c | 42 +++++++++++++
.../selftests/bpf/progs/get_func_ip_test.c | 62 +++++++++++++++++++
2 files changed, 104 insertions(+)
create mode 100644 tools/testing/selftests/bpf/prog_tests/get_func_ip_test.c
create mode 100644 tools/testing/selftests/bpf/progs/get_func_ip_test.c
[...]
+ ASSERT_OK(err, "test_run");
+
+ result = (__u64 *)skel->bss;
+ for (i = 0; i < sizeof(*skel->bss) / sizeof(__u64); i++) {
+ if (!ASSERT_EQ(result[i], 1, "fentry_result"))
+ break;
+ }
I dislike such generic loop over results. It's super error prone and
takes the same 5 lines of code that you'd write for explicit
ASSERT_EQ(testX_result, 1, "testX_result"); /* 5 times */
+
+ get_func_ip_test__detach(skel);
no need to explicitly detach, __destroy does that automatically
On Wed, Jul 7, 2021 at 2:54 PM Jiri Olsa [off-list ref] wrote:
quoted hunk
From: Alan Maguire <redacted>
kprobes can be placed on most instructions in a function, not
just entry, and ftrace and bpftrace support the function+offset
notification for probe placement. Adding parsing of func_name
into func+offset to bpf_program__attach_kprobe() allows the
user to specify
SEC("kprobe/bpf_fentry_test5+0x6")
...for example, and the offset can be passed to perf_event_open_probe()
to support kprobe attachment.
Signed-off-by: Alan Maguire <redacted>
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
---
tools/lib/bpf/libbpf.c | 20 +++++++++++++++++---
1 file changed, 17 insertions(+), 3 deletions(-)
I think we should add bpf_program__attach_kprobe_opts instead for the
programmatic API instead of parsing it here from func_name. It's a
cumbersome API.
Parsing SEC() is fine, of course, but then it has to call into
bpf_program__attach_kprobe_opts() internally.
@@ -60,3 +61,15 @@ int BPF_PROG(fmod_ret_test, int a, int *b, int ret)test5_result=(constvoid*)addr==&bpf_modify_return_test;returnret;}++#ifdef __x86_64__+__u64test6_result=0;
see, and you just forgot to update the user-space part of the test to
even check test6_result...
please group variables together and do explicit ASSERT_EQ
Why does it have to be gated by 'jited && x86_64' ?
It's gated by bpf trampoline and it's only implemented on x86_64 so far.
The trampoline has plenty of features. I would expect bpf trampoline
for arm64 to implement all of them. If not the func_ip would be just
one of the trampoline features that couldn't be implemented and at that
time we'd need a flag mask of a sort, but I'd rather push of feature
equivalence between trampoline implementations.
Then jited part also doesn't seem to be necessary.
The trampoline passed pointer to a stack in R1.
Interpreter should deal with BPF_LDX_MEM(BPF_DW, BPF_REG_0, BPF_REG_1, -8) insn
the same way and it should work, since trampoline prepared it.
What did I miss?
quoted hunk
+static int has_get_func_ip(struct bpf_verifier_env *env)
+{
+ enum bpf_attach_type eatype = env->prog->expected_attach_type;
+ enum bpf_prog_type type = resolve_prog_type(env->prog);
+ int func_id = BPF_FUNC_get_func_ip;
+
+ if (type == BPF_PROG_TYPE_TRACING) {
+ if (eatype != BPF_TRACE_FENTRY && eatype != BPF_TRACE_FEXIT &&
+ eatype != BPF_MODIFY_RETURN) {
+ verbose(env, "func %s#%d supported only for fentry/fexit/fmod_ret programs\n",
+ func_id_name(func_id), func_id);
+ return -ENOTSUPP;
+ }
+ if (!allow_get_func_ip_tracing(env)) {
+ verbose(env, "func %s#%d for tracing programs supported only for JITed x86_64\n",
+ func_id_name(func_id), func_id);
+ return -ENOTSUPP;
+ }
+ return 0;
+ }
+
+ verbose(env, "func %s#%d not supported for program type %d\n",
+ func_id_name(func_id), func_id, type);
+ return -ENOTSUPP;
+}
+
static int check_helper_call(struct bpf_verifier_env *env, struct bpf_insn *insn,
int *insn_idx_p)
{
@@ -6225,6 +6256,12 @@ static int check_helper_call(struct bpf_verifier_env *env, struct bpf_insn *insn if (func_id == BPF_FUNC_get_stackid || func_id == BPF_FUNC_get_stack) env->prog->call_get_stack = true;+ if (func_id == BPF_FUNC_get_func_ip) {+ if (has_get_func_ip(env))+ return -ENOTSUPP;+ env->prog->call_get_func_ip = true;+ }+ if (changes_data) clear_all_pkt_pointers(env); return 0;
@@ -948,6 +948,19 @@ const struct bpf_func_proto bpf_snprintf_btf_proto = {.arg5_type=ARG_ANYTHING,};+BPF_CALL_1(bpf_get_func_ip_tracing,void*,ctx)+{+/* Stub, the helper call is inlined in the program. */+return0;+}
may be add a WARN in here that it should never be executed ?
Or may be add an actual implementation:
return ((u64 *)ctx)[-1];
and check that it works without inlining by the verifier?
On Wed, 7 Jul 2021 23:47:48 +0200
Jiri Olsa [off-list ref] wrote:
Adding bpf_get_func_ip helper for BPF_PROG_TYPE_KPROBE programs,
so it's now possible to call bpf_get_func_ip from both kprobe and
kretprobe programs.
Taking the caller's address from 'struct kprobe::addr', which is
defined for both kprobe and kretprobe.
Note that the kp->addr of kretprobe will be the callee function
address, even if the handler is called when the end of the callee.
Anyway, this looks good to me.
Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org>
Thank you,
@@ -5979,6 +5979,8 @@ static int has_get_func_ip(struct bpf_verifier_env *env)return-ENOTSUPP;}return0;+}elseif(type==BPF_PROG_TYPE_KPROBE){+return0;}verbose(env,"func %s#%d not supported for program type %d\n",
Why does it have to be gated by 'jited && x86_64' ?
It's gated by bpf trampoline and it's only implemented on x86_64 so far.
The trampoline has plenty of features. I would expect bpf trampoline
for arm64 to implement all of them. If not the func_ip would be just
one of the trampoline features that couldn't be implemented and at that
time we'd need a flag mask of a sort, but I'd rather push of feature
equivalence between trampoline implementations.
ok, check for trampoline's prog types should be enough
Then jited part also doesn't seem to be necessary.
The trampoline passed pointer to a stack in R1.
Interpreter should deal with BPF_LDX_MEM(BPF_DW, BPF_REG_0, BPF_REG_1, -8) insn
the same way and it should work, since trampoline prepared it.
What did I miss?
@@ -948,6 +948,19 @@ const struct bpf_func_proto bpf_snprintf_btf_proto = {.arg5_type=ARG_ANYTHING,};+BPF_CALL_1(bpf_get_func_ip_tracing,void*,ctx)+{+/* Stub, the helper call is inlined in the program. */+return0;+}
may be add a WARN in here that it should never be executed ?
Or may be add an actual implementation:
return ((u64 *)ctx)[-1];
and check that it works without inlining by the verifier?
sure, but having tracing program with this helper, it will be
always inlined, right? I can't see how it could be skipped
thanks,
jirka
From: Jiri Olsa <hidden> Date: 2021-07-11 14:48:19
On Sat, Jul 10, 2021 at 04:55:12PM +0900, Masami Hiramatsu wrote:
On Wed, 7 Jul 2021 23:47:48 +0200
Jiri Olsa [off-list ref] wrote:
quoted
Adding bpf_get_func_ip helper for BPF_PROG_TYPE_KPROBE programs,
so it's now possible to call bpf_get_func_ip from both kprobe and
kretprobe programs.
Taking the caller's address from 'struct kprobe::addr', which is
defined for both kprobe and kretprobe.
Note that the kp->addr of kretprobe will be the callee function
address, even if the handler is called when the end of the callee.
yes, that's what we need
Anyway, this looks good to me.
Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org>
@@ -5979,6 +5979,8 @@ static int has_get_func_ip(struct bpf_verifier_env *env)return-ENOTSUPP;}return0;+}elseif(type==BPF_PROG_TYPE_KPROBE){+return0;}verbose(env,"func %s#%d not supported for program type %d\n",
@@ -60,3 +61,15 @@ int BPF_PROG(fmod_ret_test, int a, int *b, int ret)test5_result=(constvoid*)addr==&bpf_modify_return_test;returnret;}++#ifdef __x86_64__+__u64test6_result=0;
see, and you just forgot to update the user-space part of the test to
even check test6_result...
please group variables together and do explicit ASSERT_EQ
From: Jiri Olsa <hidden> Date: 2021-07-11 14:48:34
On Wed, Jul 07, 2021 at 05:06:17PM -0700, Andrii Nakryiko wrote:
On Wed, Jul 7, 2021 at 2:53 PM Jiri Olsa [off-list ref] wrote:
quoted
Adding bpf_get_func_ip helper for BPF_PROG_TYPE_TRACING programs,
specifically for all trampoline attach types.
The trampoline's caller IP address is stored in (ctx - 8) address.
so there's no reason to actually call the helper, but rather fixup
the call instruction and return [ctx - 8] value directly (suggested
by Alexei).
[fixed has_get_func_ip wrong return type]
Reported-by: kernel test robot <redacted>
Reported-by: Dan Carpenter <redacted>
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
---
include/uapi/linux/bpf.h | 7 +++++
kernel/bpf/verifier.c | 53 ++++++++++++++++++++++++++++++++++
kernel/trace/bpf_trace.c | 15 ++++++++++
tools/include/uapi/linux/bpf.h | 7 +++++
4 files changed, 82 insertions(+)
[...]
quoted
static int check_helper_call(struct bpf_verifier_env *env, struct bpf_insn *insn,
int *insn_idx_p)
{
@@ -6225,6 +6256,12 @@ static int check_helper_call(struct bpf_verifier_env *env, struct bpf_insn *insn if (func_id == BPF_FUNC_get_stackid || func_id == BPF_FUNC_get_stack) env->prog->call_get_stack = true;+ if (func_id == BPF_FUNC_get_func_ip) {+ if (has_get_func_ip(env))
from has_xxx name I'd expect it returns true/false, so this reads
super confusing. check_get_func_ip would be a bit more consistent with
other cases like this (still reads confusing to me, but that's ok)
From: Jiri Olsa <hidden> Date: 2021-07-11 14:48:41
On Wed, Jul 07, 2021 at 05:12:07PM -0700, Andrii Nakryiko wrote:
On Wed, Jul 7, 2021 at 2:54 PM Jiri Olsa [off-list ref] wrote:
quoted
Adding test for bpf_get_func_ip helper for fentry, fexit,
kprobe, kretprobe and fmod_ret programs.
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
---
.../bpf/prog_tests/get_func_ip_test.c | 42 +++++++++++++
.../selftests/bpf/progs/get_func_ip_test.c | 62 +++++++++++++++++++
2 files changed, 104 insertions(+)
create mode 100644 tools/testing/selftests/bpf/prog_tests/get_func_ip_test.c
create mode 100644 tools/testing/selftests/bpf/progs/get_func_ip_test.c
[...]
quoted
+ ASSERT_OK(err, "test_run");
+
+ result = (__u64 *)skel->bss;
+ for (i = 0; i < sizeof(*skel->bss) / sizeof(__u64); i++) {
+ if (!ASSERT_EQ(result[i], 1, "fentry_result"))
+ break;
+ }
I dislike such generic loop over results. It's super error prone and
takes the same 5 lines of code that you'd write for explicit
ASSERT_EQ(testX_result, 1, "testX_result"); /* 5 times */
ok
quoted
+
+ get_func_ip_test__detach(skel);
no need to explicitly detach, __destroy does that automatically
From: Jiri Olsa <hidden> Date: 2021-07-11 14:48:50
On Wed, Jul 07, 2021 at 05:14:20PM -0700, Andrii Nakryiko wrote:
On Wed, Jul 7, 2021 at 2:54 PM Jiri Olsa [off-list ref] wrote:
quoted
From: Alan Maguire <redacted>
kprobes can be placed on most instructions in a function, not
just entry, and ftrace and bpftrace support the function+offset
notification for probe placement. Adding parsing of func_name
into func+offset to bpf_program__attach_kprobe() allows the
user to specify
SEC("kprobe/bpf_fentry_test5+0x6")
...for example, and the offset can be passed to perf_event_open_probe()
to support kprobe attachment.
Signed-off-by: Alan Maguire <redacted>
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
---
tools/lib/bpf/libbpf.c | 20 +++++++++++++++++---
1 file changed, 17 insertions(+), 3 deletions(-)
I think we should add bpf_program__attach_kprobe_opts instead for the
programmatic API instead of parsing it here from func_name. It's a
cumbersome API.
Parsing SEC() is fine, of course, but then it has to call into
bpf_program__attach_kprobe_opts() internally.
ok, Alan, will you make the change, or should I do that?
thanks,
jirka
On Sun, Jul 11, 2021 at 7:48 AM Jiri Olsa [off-list ref] wrote:
On Wed, Jul 07, 2021 at 05:18:49PM -0700, Andrii Nakryiko wrote:
quoted
On Wed, Jul 7, 2021 at 2:54 PM Jiri Olsa [off-list ref] wrote:
quoted
Adding test for bpf_get_func_ip in kprobe+ofset probe.
typo: offset
quoted
Because of the offset value it's arch specific, adding
it only for x86_64 architecture.
I'm not following, you specified +0x5 offset explicitly, why is this
arch-specific?
I need some instruction offset != 0 in the traced function,
x86_64's fentry jump is 5 bytes, other archs will be different
Right, ok. I don't see an easy way to detect this offset, but the
#ifdef __x86_64__ detection doesn't work because we are compiling with
-target bpf. Please double-check that it actually worked in the first
place.
I think a better way would be to have test6 defined unconditionally in
BPF code, but then disable loading test6 program on anything but
x86_64 platform at runtime with bpf_program__set_autoload(false).
@@ -60,3 +61,15 @@ int BPF_PROG(fmod_ret_test, int a, int *b, int ret)test5_result=(constvoid*)addr==&bpf_modify_return_test;returnret;}++#ifdef __x86_64__+__u64test6_result=0;
see, and you just forgot to update the user-space part of the test to
even check test6_result...
please group variables together and do explicit ASSERT_EQ
From: Jiri Olsa <hidden> Date: 2021-07-13 14:15:22
On Mon, Jul 12, 2021 at 04:32:25PM -0700, Andrii Nakryiko wrote:
On Sun, Jul 11, 2021 at 7:48 AM Jiri Olsa [off-list ref] wrote:
quoted
On Wed, Jul 07, 2021 at 05:18:49PM -0700, Andrii Nakryiko wrote:
quoted
On Wed, Jul 7, 2021 at 2:54 PM Jiri Olsa [off-list ref] wrote:
quoted
Adding test for bpf_get_func_ip in kprobe+ofset probe.
typo: offset
quoted
Because of the offset value it's arch specific, adding
it only for x86_64 architecture.
I'm not following, you specified +0x5 offset explicitly, why is this
arch-specific?
I need some instruction offset != 0 in the traced function,
x86_64's fentry jump is 5 bytes, other archs will be different
Right, ok. I don't see an easy way to detect this offset, but the
#ifdef __x86_64__ detection doesn't work because we are compiling with
-target bpf. Please double-check that it actually worked in the first
place.
ugh, right
I think a better way would be to have test6 defined unconditionally in
BPF code, but then disable loading test6 program on anything but
x86_64 platform at runtime with bpf_program__set_autoload(false).
great, I did not know about this function, will be easier
thanks,
jirka
@@ -60,3 +61,15 @@ int BPF_PROG(fmod_ret_test, int a, int *b, int ret)test5_result=(constvoid*)addr==&bpf_modify_return_test;returnret;}++#ifdef __x86_64__+__u64test6_result=0;
see, and you just forgot to update the user-space part of the test to
even check test6_result...
please group variables together and do explicit ASSERT_EQ