2

My environment:

  1. aarch64-linux-5.15.7
  2. bpf compile tools: clang-11
  3. bpf compile param:
clang -g -target bpf -Wall -O2 -g3 -g -DBPF_CODE -ggdb -std=gnu99 -D__TARGET_ARCH_arm64 -Wno-compare-distinct-pointer-types
  1. Using libbpf 1.0.1/bpf_object__load() fails after open

Errors

  1. Using __sync_add_and_fetch returns ENOTSUPP. The Linux kernel code returns the error code as follows:
if (attr->attach_prog_fd) {

    dst_prog = bpf_prog_get(attr->attach_prog_fd);

    if (IS_ERR(dst_prog)) {

        dst_prog = NULL;
        attach_btf = btf_get_by_fd(attr->attach_btf_obj_fd);

        if (IS_ERR(attach_btf))
            return -EINVAL;

        if (!btf_is_kernel(attach_btf)) {
            /* attaching through specifying bpf_prog's BTF
             * objects directly might be supported eventually
             */
            btf_put(attach_btf);
            return -ENOTSUPP;
        }
    }
}

I also tried to disabling the btf type function in the kernel. The exception was still displayed. The same code was running properly on x86.

  1. Using atomic64_add produces the error info as follows:
libbpf: failed to find BTF for extern'atomic64_add': - 2

Check the Linux update description and related code. This version supports atomic operations.

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
Jefen
  • 21
  • 2
  • Does anyone know this better and can help me? – Jefen Apr 21 '23 at 03:42
  • 1
    @NickS1: I made a couple corrections to your edit. The formatting improvements are great, but don't change C89-style comments to `//` comments for no reason, especially in a code block that's probably quoted verbatim from upstream code, perhaps the Linux kernel. Also, "aarch" was probably a typo for "aarch64", since they did later mention "arm64". I also reverted your rewrite of the sentence introducing that code block, since I don't think the original is clear enough for either of us to be sure what they meant. (So the OP should improve that, but for now leave it.) – Peter Cordes Apr 21 '23 at 04:25
  • Hello @PeterCordes, I am really sorry for this. I should've been more careful and less invasive when editing the question. Thank you pointing this out . – NickS1 Apr 21 '23 at 04:33
  • 1
    @NickS1: No worries, mistakes happen, that's why they bump the question for people following recent questions in a tag. (And why we have review queues for low-rep users who usually aren't as experienced with making edits.) – Peter Cordes Apr 21 '23 at 04:45
  • Regarding the kernel code snippet you shared, are you sure the ENOTSUPP you get comes from there? How did you check? Did you also try to dump the verifier logs in case something was written there? – pchaigno Apr 23 '23 at 17:10
  • @pchaigno I traced the bpf_object_load() function of the libbpf library and found that it did call the system call and returned an error. I looked at the related system call function in the kernel and found that only the part I looked at returned the error. That's why I think it's the logic. If I want, I can add a segment print in the kernel to confirm where the error occurred. ps. Thanks for the editing of the version to make the problem clearer. – Jefen May 06 '23 at 09:37

0 Answers0