On Tue, Nov 26, 2024 at 9:06 AM Maciej Fijalkowski <maciej.fijalkowski@xxxxxxxxx> wrote: > > Hello eBPFers, > > I have a use case where I would like to store sk_buff pointers as kptrs in > eBPF map. To do so, I am borrowing skb kfuncs for acquire/release/destroy > from Amery Hung's bpf qdisc set [0], but they are registered for > BPF_PROG_TYPE_SCHED_CLS programs. > > TL;DR - due to following callstack: > > do_check() > check_kfunc_call() > check_kfunc_args() > get_kfunc_ptr_arg_type() > btf_is_prog_ctx_type() > btf_is_projection_of() -- return true > > sk_buff argument is being interpreted as KF_ARG_PTR_TO_CTX, but what we > have there is KF_ARG_PTR_TO_BTF_ID. Verifier is unhappy about it. Should > this be workarounded via some typedef or adding mentioned kfuncs to > special_kfunc_list ? If the latter, then what else needs to be handled? > > Commenting out sk_buff part from btf_is_projection_of() makes it work, but > that probably is not a solution:) > > Another question is in case bpf qdisc set lands, could we have these > kfuncs not being limited to BPF_PROG_TYPE_STRUCT_OPS ? > Hi Maciej, bpf qdisc will use a different mechanism to acquire skb referenced kptrs (i.e., no skb-acquiring kfunc). For skb-releasing kfunc, I don't think it can be made available to SCHED_CLS programs directly either. The problem is the bpf program could kfree_skb() the skb in the ctx with this kfunc. However, the kernel is still expecting a valid skb later in cls_bpf_classify(). Another potential problem to consider in order to enable skb kptrs in SCHED_CLS is the cleanup. In bpf qdisc case, we are still working on releasing skb kptrs in maps or graphs automatically when .reset is called so that we don't hold the resources forever. I am interested in hearing your use case of storing skb kptr in maps. Do you mind sharing it? Thanks, Amery > I would be thankful for any pointers/stions regarding this issue. > Maciej > > [0]: https://lore.kernel.org/bpf/20240714175130.4051012-7-amery.hung@xxxxxxxxxxxxx/
