On Tue, May 31, 2022 at 7:16 PM John Mazzie <john.p.mazzie@xxxxxxxxx> wrote:
>
> I pulled the latest libbpf-bootstrap and rebuilt my programs. The
> error message is clearer now. I think last time I tried
> libbpf-bootstrap was still linked to 0.7 instead of 0.8.
>
> The new message is the following which makes sense in regard to what you said.
>
> <invalid CO-RE relocation>
> failed to resolve CO-RE relocation <byte_off> [14] struct
> nvme_command.common.opcode (0:0:0:0 @ offset 0)
> processed 8 insns (limit 1000000) max_states_per_insn 0 total_states 0
> peak_states 0 mark_read 0
>
> This struct is part of the nvme driver, which is running on this
> system as it only has nvme devices (including boot device). I've been
> able to access this data using bpftrace on the same system. If I don't
> try to access this struct I can count the correct number of
> nvme_submit_cmd triggers, so I believe the probe is working correctly.
> Is this a case where I need to define more/all of the struct?
>
Look at debug logs from libbpf. I tried simplified version of your
program and it all works for me.
struct nvme_common_command {
__u8 opcode;
} __attribute__((preserve_access_index));
struct nvme_command {
union {
struct nvme_common_command common;
};
} __attribute__((preserve_access_index));
SEC("kprobe/nvme_submit_cmd")
int BPF_KPROBE(nvme_submit_cmd, void *nvmeq, struct nvme_command *cmd,
bool write_sq)
{
bpf_printk("OPCODE %d", BPF_CORE_READ(cmd, common.opcode));
return 0;
}
Libbpf logs:
libbpf: sec 'kprobe/nvme_submit_cmd': found 2 CO-RE relocations
libbpf: CO-RE relocating [6] struct pt_regs: found target candidate
[226] struct pt_regs in [vmlinux]
libbpf: prog 'nvme_submit_cmd': relo #0: kind <byte_off> (0), spec is
[6] struct pt_regs.si (0:13 @ offset 104)
libbpf: prog 'nvme_submit_cmd': relo #0: matching candidate #0 [226]
struct pt_regs.si (0:13 @ offset 104)
libbpf: prog 'nvme_submit_cmd': relo #0: patched insn #0 (LDX/ST/STX)
off 104 -> 104
libbpf: CO-RE relocating [10] struct nvme_command: found target
candidate [107390] struct nvme_command in [nvme_core]
libbpf: CO-RE relocating [10] struct nvme_command: found target
candidate [106451] struct nvme_command in [nvme]
libbpf: prog 'nvme_submit_cmd': relo #1: kind <byte_off> (0), spec is
[10] struct nvme_command.common.opcode (0:0:0:0 @ offset 0)
libbpf: prog 'nvme_submit_cmd': relo #1: matching candidate #0
[107390] struct nvme_command.common.opcode (0:0:0:0 @ offset 0)
libbpf: prog 'nvme_submit_cmd': relo #1: matching candidate #1
[106451] struct nvme_command.common.opcode (0:0:0:0 @ offset 0)
libbpf: prog 'nvme_submit_cmd': relo #1: patched insn #1 (ALU/ALU64) imm 0 -> 0
Successfully started! Please run `sudo cat
/sys/kernel/debug/tracing/trace_pipe` to see output of the BPF
programs.
..............^C
> On Tue, May 31, 2022 at 7:22 PM Andrii Nakryiko
> <andrii.nakryiko@xxxxxxxxx> wrote:
> >
> > On Fri, May 27, 2022 at 3:07 AM John Mazzie <john.p.mazzie@xxxxxxxxx> wrote:
> > >
> > > While attempting to learn more about BPF and libbpf, I ran into an
> > > issue I can't quite seem to resolve.
> > >
> > > While writing some tools to practice tracing with libbpf, I came
> > > across a situation where I get an error when using BPF_CORE_READ,
> > > which appears to be that CO-RE relocation failed to find a
> > > corresponding field. Compilation doesn't complain, just when I try to
> > > execute.
> > >
> > > Error Message:
> > > ---------------------------------------------
> > > 8: (85) call unknown#195896080
> > > invalid func unknown#195896080
> >
> > This means CO-RE relocation failed. If you update libbpf submodule (or
> > maybe we already did it for libbpf-bootstrap recently), you'll get
> > more meaningful error and details. But basically in running kernel
> > there is no cmd->common.opcode.
> >
> > >
> > > I'm using the Makefile from libbpf-bootstrap to build my program. The
> > > other example programs build and execute properly, and I've also
> > > successfully used tracepoints to trace the nvme_setup_cmd and
> > > nvme_complete_rq functions. My issue appears to be when I attempt to
> > > use kprobes for the nvme_submit_cmd function.
> > >
> >
> > [...]
