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. > 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 >
