"
On Thu, Nov 10, 2022 at 3:58 PM Martin KaFai Lau <martin.lau@xxxxxxxxx> wrote:
>
> On 11/10/22 10:52 AM, Stanislav Fomichev wrote:
> >>> Oh, that seems even better than returning it from
> >>> bpf_xdp_metadata_export_to_skb.
> >>> bpf_xdp_metadata_export_to_skb can return true/false and the rest goes
> >>> via default verifier ctx resolution mechanism..
> >>> (returning ptr from a kfunc seems to be a bit complicated right now)
>
> What is the complication in returning ptr from a kfunc? I want to see if it can
> be solved because it will be an easier API to use instead of calling another
> kfunc to get the ptr.
At least for returning a pointer to the basic c types like int/long, I
was hitting the following:
commit eb1f7f71c126c8fd50ea81af98f97c4b581ea4ae
Author: Benjamin Tissoires <benjamin.tissoires@xxxxxxxxxx>
AuthorDate: Tue Sep 6 17:13:02 2022 +0200
Commit: Alexei Starovoitov <ast@xxxxxxxxxx>
CommitDate: Wed Sep 7 11:05:17 2022 -0700
bpf/verifier: allow kfunc to return an allocated mem
Where I had to add an extra "const int rdonly_buf_size" argument to
the kfunc to make the verifier happy.
But I haven't really looked at what would happen with the pointers to
structs (or why, at all, we have this restriction).
> >> See my response to John in the other thread about mixing stable UAPI (in
> >> xdp_md) and unstable BTF structures in the xdp_md struct: I think this
> >> is confusing and would prefer a kfunc.
>
> hmm... right, it will be one of the first considering the current __bpf_md_ptr()
> usages are only exposing another struct in uapi, eg. __bpf_md_ptr(struct
> bpf_sock *, sk).
>
> A kfunc will also be fine.
>
