On Mon, Dec 19, 2016 at 8:44 PM, Alexei Starovoitov
<alexei.starovoi...@gmail.com> wrote:
> On Mon, Dec 19, 2016 at 07:12:48PM -0800, Andy Lutomirski wrote:
>>
>> struct cgroup_bpf {
>> /*
>> * Store two sets of bpf_prog pointers, one for programs that are
>> * pinned directly to this cgroup, and one for those that are
>> effective
>> * when this cgroup is accessed.
>> */
>> struct bpf_prog *prog[MAX_BPF_ATTACH_TYPE];
>> struct bpf_prog *effective[MAX_BPF_ATTACH_TYPE];
>> };
>>
>> in struct cgroup, there's a 'struct cgroup_bpf bpf;'.
>>
>> This would change to something like:
>>
>> struct cgroup_filter_slot {
>> struct bpf_prog *effective;
>> struct cgroup_filter_slot *next;
>> struct bpf_prog *local;
>> }
>>
>> local is NULL unless *this* cgroup has a filter. effective points to
>> the bpf_prog that's active in this cgroup or the nearest ancestor that
>> has a filter. next is NULL if there are no filters higher in the
>> chain or points to the next slot that has a filter. struct cgroup
>> has:
>>
>> struct cgroup_filter_slot filters[MAX_BPF_ATTACH_TYPE];
>>
>> To evaluate it, you do:
>>
>> struct cgroup_filter_slot *slot = &cgroup->slot[the index];
>>
>> if (!slot->effective)
>> return;
>>
>> do {
>> evaluate(slot->effective);
>> slot = slot->next;
>> } while (unlikely(slot));
>
> yes. something like this can work as a future extension
> to support multiple programs for security use case.
> Please propose a patch.
> Again, it's not needed today and there is no rush to implement it.
>
If this happens after 4.10 and 4.10 is released as is, then this
change would be an ABI break.
--Andy
