On Tue, 23 Aug 2022 at 10:29, John Fastabend <john.fastabend@xxxxxxxxx> wrote: > > Kumar Kartikeya Dwivedi wrote: > > They would require func_info which needs prog BTF anyway. Loading BTF > > and setting the prog btf_fd while loading the prog indirectly requires > > CAP_BPF, so just to reduce confusion, move both these helpers taking > > callback under bpf_capable() protection as well, since they cannot be > > used without CAP_BPF. > > > > Signed-off-by: Kumar Kartikeya Dwivedi <memxor@xxxxxxxxx> > > --- > > This should have a fixes tag IMO. You'll get unexpected results if we > don't have get it backported to the right places. > Hm, I was unsure if this requires a Fixes tag. It's technically not a fix, it's a minor reorg in my opinion (could have gone through bpf-next as well) which has no real resulting change for users loading programs, and makes things less confusing. The actual fix in patch 2 is independent of this change. > > kernel/bpf/helpers.c | 8 ++++---- > > 1 file changed, 4 insertions(+), 4 deletions(-) > > > > diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c > > index 1f961f9982d2..d0e80926bac5 100644 > > --- a/kernel/bpf/helpers.c > > +++ b/kernel/bpf/helpers.c > > @@ -1633,10 +1633,6 @@ bpf_base_func_proto(enum bpf_func_id func_id) > > return &bpf_ringbuf_submit_dynptr_proto; > > case BPF_FUNC_ringbuf_discard_dynptr: > > return &bpf_ringbuf_discard_dynptr_proto; > > - case BPF_FUNC_for_each_map_elem: > > - return &bpf_for_each_map_elem_proto; > > - case BPF_FUNC_loop: > > - return &bpf_loop_proto; > > case BPF_FUNC_strncmp: > > return &bpf_strncmp_proto; > > case BPF_FUNC_dynptr_from_mem: > > @@ -1675,6 +1671,10 @@ bpf_base_func_proto(enum bpf_func_id func_id) > > return &bpf_timer_cancel_proto; > > case BPF_FUNC_kptr_xchg: > > return &bpf_kptr_xchg_proto; > > + case BPF_FUNC_for_each_map_elem: > > + return &bpf_for_each_map_elem_proto; > > + case BPF_FUNC_loop: > > + return &bpf_loop_proto; > > default: > > break; > > } > > -- > > 2.34.1 > > > >
