All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yonghong Song <yhs@fb.com>
To: Hou Tao <houtao1@huawei.com>, Martin KaFai Lau <kafai@fb.com>
Cc: bpf <bpf@vger.kernel.org>, Alexei Starovoitov <ast@kernel.org>,
	Andrii Nakryiko <andrii@kernel.org>
Subject: Re: Question about pointer to forward type
Date: Tue, 2 Nov 2021 20:58:12 -0700	[thread overview]
Message-ID: <050ba6c6-c7b2-528c-b616-030b7b14d67e@fb.com> (raw)
In-Reply-To: <c19f223e-2ef5-9f9a-f741-2fcc7d89fef6@huawei.com>



On 10/15/21 7:22 AM, Hou Tao wrote:
> Hi,
> 
> When adding test case for BPF STRUCT OPS, I got the following error
> during test:
> 
> libbpf: load bpf program failed: Permission denied
> libbpf: -- BEGIN DUMP LOG ---
> libbpf:
> R1 type=ctx expected=fp
> ; int BPF_PROG(test_1, struct bpf_dummy_ops_state *state)
> 0: (b4) w0 = -218893067
> ; int BPF_PROG(test_1, struct bpf_dummy_ops_state *state)
> 1: (79) r1 = *(u64 *)(r1 +0)
> func 'test_1' arg0 type FWD is not a struct
> invalid bpf_context access off=0 size=8
> 
> The error is reported from btf_ctx_access(). And the cause is
> the definition of struct bpf_dummy_ops_state is separated from
> the definition of test_1 function:
> 
> test_1 is defined in include/linux/bpf.h
> 
> struct bpf_dummy_ops_state;
> struct bpf_dummy_ops {
>          int (*test_1)(struct bpf_dummy_ops_state *cb);
> }
> 
> bpf_dummy_ops_state is defined in net/bpf/bpf_dummy_struct_ops.c
> 
> struct bpf_dummy_ops_state {
> };
> 
> So arg0 has BTF_KIND_FWD type, and the check in btf_ctx_access() fails.
> The problem can be fixed by moving the definition of bpf_dummy_ops_state
> into include/linux/bpf.h or using a void * instead of
> struct bpf_dummy_ops_state *. But forward declaration is possible under
> STRUCT_OPS scenario, so my question is whether or not it is a known issue
> and is there somebody working on this ?

I suspect this is what happened.
The 'struct bpf_dummy_ops_state' is defined in 
net/bpf/bpf_dummy_struct_ops.c, but this structure is not used in that file
so there is no definition in the bpf_dummy_struct_ops.o dwarf.

Since in the final combined dwarf, there is no "struct 
bpf_dummy_ops_state" definition, dedup won't be able to replace
forward declaration with actual definition. And this caused
your above issue.

It would be good if you can verifier whether this is the case or
not. If bpf_dummy_ops_state definition is in the dwarf, then we
likely have a dedup problem.

> 
> Regards,
> Tao
> 

  reply	other threads:[~2021-11-03  3:58 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-15 14:22 Question about pointer to forward type Hou Tao
2021-11-03  3:58 ` Yonghong Song [this message]
2021-11-03 11:00   ` Hou Tao
2021-11-03 19:22     ` Yonghong Song

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=050ba6c6-c7b2-528c-b616-030b7b14d67e@fb.com \
    --to=yhs@fb.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=houtao1@huawei.com \
    --cc=kafai@fb.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.