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.
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
