On 8/31/17 8:22 AM, Tejun Heo wrote: > On Sun, Aug 27, 2017 at 08:49:23AM -0600, David Ahern wrote: >> On 8/25/17 8:49 PM, Alexei Starovoitov wrote: >>> >>>> + if (prog && curr_recursive && !new_recursive) >>>> + /* if a parent has recursive prog attached, only >>>> + * allow recursive programs in descendent cgroup >>>> + */ >>>> + return -EINVAL; >>>> + >>>> old_prog = cgrp->bpf.prog[type]; >>> >>> ... I'm struggling to completely understand how it interacts >>> with BPF_F_ALLOW_OVERRIDE. >> >> The 2 flags are completely independent. The existing override logic is >> unchanged. If a program can not be overridden, then the new recursive >> flag is irrelevant. > > I'm not sure all four combo of the two flags makes sense. Can't we > have something simpler like the following? > > 1. None: No further bpf programs allowed in the subtree. > > 2. Overridable: If a sub-cgroup installs the same bpf program, this > one yields to that one. > > 3. Recursive: If a sub-cgroup installs the same bpf program, that > cgroup program gets run in addition to this one. > > Note that we can have combinations of overridables and recursives - > both allow further programs in the sub-hierarchy and the only > distinction is whether that specific program behaves when that > happens. >
I am going to send v3 for patches 2-6 and 8 - the uncontested patches. Alexei and I will meet in L.A. the week of Sept 11-15 to discuss the recursive implementation (Patch 1 and its testing, patch 7).
