All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Mazzie <john.p.mazzie@gmail.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: bpf <bpf@vger.kernel.org>, "John Mazzie (jmazzie)" <jmazzie@micron.com>
Subject: Re: BPF_CORE_READ issue with nvme_submit_cmd kprobe.
Date: Tue, 31 May 2022 21:16:37 -0500	[thread overview]
Message-ID: <CAPxVHdJL6-m3BbDSaHOn_kq31cBh2LEHeEqNnw7ecOXz7Aqijg@mail.gmail.com> (raw)
In-Reply-To: <CAEf4BzbiiZd7OJxN17=3ikZTor_mcqVO2XTdK6dbpcm9NqgX8w@mail.gmail.com>

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?

On Tue, May 31, 2022 at 7:22 PM Andrii Nakryiko
<andrii.nakryiko@gmail.com> wrote:
>
> On Fri, May 27, 2022 at 3:07 AM John Mazzie <john.p.mazzie@gmail.com> 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.
> >
>
> [...]

  reply	other threads:[~2022-06-01  2:16 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-26 19:15 BPF_CORE_READ issue with nvme_submit_cmd kprobe John Mazzie
2022-06-01  0:22 ` Andrii Nakryiko
2022-06-01  2:16   ` John Mazzie [this message]
2022-06-01  4:51     ` Andrii Nakryiko
2022-06-01 18:06       ` John Mazzie
2022-06-01 21:43         ` Andrii Nakryiko
2022-06-02  0:03           ` John Mazzie

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=CAPxVHdJL6-m3BbDSaHOn_kq31cBh2LEHeEqNnw7ecOXz7Aqijg@mail.gmail.com \
    --to=john.p.mazzie@gmail.com \
    --cc=andrii.nakryiko@gmail.com \
    --cc=bpf@vger.kernel.org \
    --cc=jmazzie@micron.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.