Re: Ideal way to read FUNC_PROTO in raw tp?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Jun 21, 2024 at 5:04 PM Andrii Nakryiko
<andrii.nakryiko@xxxxxxxxx> wrote:
>
> On Thu, Jun 6, 2024 at 3:03 PM Yan Zhai <yan@xxxxxxxxxxxxxx> wrote:
> >
> > Hi,
> >
> >  I am building a tracing program around workqueue. But I encountered
> > following problem when I try to record a function pointer value from
> > trace_workqueue_execute_end on net-next kernel:
> >
> > ...
> > libbpf: prog 'workqueue_end': BPF program load failed: Permission
> > denied
> > libbpf: prog 'workqueue_end': -- BEGIN PROG LOAD LOG --
> > reg type unsupported for arg#0 function workqueue_end#5
> > 0: R1=ctx(off=0,imm=0) R10=fp0
> > ; int BPF_PROG(workqueue_end, struct work_struct *w, work_func_t f)
> > 0: (79) r3 = *(u64 *)(r1 +8)
> > func 'workqueue_execute_end' arg1 type FUNC_PROTO is not a struct
> > invalid bpf_context access off=8 size=8
> > processed 1 insns (limit 1000000) max_states_per_insn 0 total_states 0
> > peak_states 0 mark_read 0
> > -- END PROG LOAD LOG --
> > libbpf: prog 'workqueue_end': failed to load: -13
> > libbpf: failed to load object 'configs/test.bpf.o'
> > Error: failed to load object file
> > Warning: bpftool is now running in libbpf strict mode and has more
> > stringent requirements about BPF programs.
> > If it used to work for this object file but now doesn't, see --legacy
> > option for more details.
> > ...
> >
> > A simple reproducer for me is like:
> > #include "vmlinux.h"
> > #include <bpf/bpf_helpers.h>
> > #include <bpf/bpf_tracing.h>
> >
> > SEC("tp_btf/workqueue_execute_end")
> > int BPF_PROG(workqueue_end, struct work_struct *w, work_func_t f)
> > {
> >         u64 addr = (u64) f;
>
> you can work around with:
>
> bpf_probe_read_kernel(&addr, sizeof(addr), &ctx[1]); /* ctx[1] is the
> second argument */
>
> Not great, but will get you past this easily.
>
Yes that works, too. Currently I am using the regular tp to
workaround. That said, I am more interested in the verifier side of
this. I am happy to add it to my queue if no one has signed up to
support func_proto type in ctx. Would maintainers welcome RFC patches
for this or is it something that you prefer to leave for now?

best
Yan





[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux