On Wed, Apr 27, 2022 at 10:47:48AM -0700, Stanislav Fomichev wrote: > Regarding cgroup_id+attach_type key of local storage: maybe prohibit > that mode for BPF_LSM_CGROUP ? We have two modes: (1) keyed by > cgroup_id+attach_type and (2) keyed by cgroup_id only (and might be > shared across attach_types). The first one never made much sense to > me; the second one behaves exactly like the rest of local storages > (file/sk/etc). WDYT? (we can enable (1) if we ever decide that it's > needed) Ah right, cgroup local_storage has already allowed keys in different granularity and is using key_size to decide which part of the bpf_cgroup_storage_key should be used. In that case, may be just allow (1) and (2) now to avoid a new inconsistent usage surprise with other existing cgroup's prog type. In the future, if a more granular cgroup local_storage is needed, the attach_btf_id can be added to 'struct bpf_cgroup_storage_key'. The existing non BPF_LSM_CGROUP prog will always have attach_btf_id 0. Would that work? One caveat though, sizeof(bpf_cgroup_storage_key) is 16 now with 4 bytes padding at the end, so the future __u32 attach_btf_id may not be able to use the padding in order to get a different size. I think it is minor and should be ok.
