Re: [PATCH v2 net] bpf: introduce BPF_F_ALLOW_OVERRIDE flag

[Alexei Starovoitov <ast@fb.com>]

On 2/11/17 9:47 PM, Tejun Heo wrote:
> On Fri, Feb 10, 2017 at 08:28:24PM -0800, Alexei Starovoitov wrote:
>> If BPF_F_ALLOW_OVERRIDE flag is used in BPF_PROG_ATTACH command
>> to the given cgroup the descendent cgroup will be able to override
>> effective bpf program that was inherited from this cgroup.
>> By default it's not passed, therefore override is disallowed.
>>
>> Examples:
>> 1.
>> prog X attached to /A with default
>> prog Y fails to attach to /A/B and /A/B/C
>> Everything under /A runs prog X
>>
>> 2.
>> prog X attached to /A with allow_override.
>> prog Y fails to attach to /A/B with default (non-override)
>> prog M attached to /A/B with allow_override.
>> Everything under /A/B runs prog M only.
>>
>> 3.
>> prog X attached to /A with allow_override.
>> prog Y fails to attach to /A with default.
>> The user has to detach first to switch the mode.
>>
>> In the future this behavior may be extended with a chain of
>> non-overridable programs.
>>
>> Also fix the bug where detach from cgroup where nothing is attached
>> was not throwing error. Return ENOENT in such case.
>>
>> Add several testcases and adjust libbpf.
>>
>> Fixes: 3007098494be ("cgroup: add support for eBPF programs")
>> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
>
> The cgroup part looks good to me.  Please feel free to add
>
> Acked-by: Tejun Heo <tj@kernel.org>
>
> One question tho.  Is there a specific reason to disallow attaching
> !overridable program under an overridable one?  Isn't disallowing
> attaching programs if the closest ancestor is !overridable enough?

yes. I felt the same way and v1 patch did that, but
as Andy pointed out the more strict rules will be easier to
extend later, so this v2 patch is using this approach.

Andy, ping !