On Mon, Dec 19, 2016 at 4:25 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: > On Mon, Dec 19, 2016 at 4:02 PM, Alexei Starovoitov > <alexei.starovoitov@xxxxxxxxx> wrote: >> you're ignoring use cases I described earlier. >> In vrf case there is only one ifindex it needs to bind to. > > I'm totally lost. Can you explain what this has to do with the cgroup > hierarchy? > Okay, I figured out what you mean, I think. You have a handful of vrf devices. Let's say they have ifindexes 1 and 2 (and maybe more). The interesting case happens when you set up /cgroup/a with a bpf program that binds new sockets to ifindex 1 and /cgroup/a/b with a bpf program that binds new sockets to ifindex 2. The question is: what should happen if you're in /cgroup/a/b? Presumably, if you do this, you wanted to end up with ifindex 2. I think the way it should actually work is that the kernel evaluates /cgroup/a/b's hook and then /cgroup/a's hook. Then /cgroup/a (which is the more privileged hook) gets to make the choice. If it wants ifindex 2 to win, it can do (pseudocode): if (!sk->sk_bound_if) sk->sk_bound_if = 1; -- 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
