On Thu, May 4, 2023 at 3:55 PM Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > > On Thu, May 04, 2023 at 03:51:16PM -0700, Andrii Nakryiko wrote: > > On Thu, May 4, 2023 at 1:05 PM Alexei Starovoitov > > <alexei.starovoitov@xxxxxxxxx> wrote: > > > > > > On Tue, May 02, 2023 at 04:06:13PM -0700, Andrii Nakryiko wrote: > > > > } > > > > > > > > -static struct bpf_map *array_map_alloc(union bpf_attr *attr) > > > > +static u32 array_index_mask(u32 max_entries) > > > > { > > > > - bool percpu = attr->map_type == BPF_MAP_TYPE_PERCPU_ARRAY; > > > > - int numa_node = bpf_map_attr_numa_node(attr); > > > > - u32 elem_size, index_mask, max_entries; > > > > - bool bypass_spec_v1 = bpf_bypass_spec_v1(); > > > > > > static inline bool bpf_bypass_spec_v1(void) > > > { > > > return perfmon_capable(); > > > } > > > > > > > + /* unprivileged is OK, but we still record if we had CAP_BPF */ > > > > + unpriv = !bpf_capable(); > > > > > > map->unpriv flag makes sense as !CAP_BPF, > > > but it's not equivalent to bpf_bypass_spec_v1. > > > > > > > argh, right, it's perfmon_capable() :( > > > > what do you propose? do bpf_capable and perfmon_capable fields for > > each map separately? or keep unpriv and add perfmon_capable > > separately? or any better ideas?.. > > Instead of map->unpriv I'd add map->bpf_capable and map->perfmon_capable > just like we'll be doing to progs. ok, sounds good!