On Sat, Feb 4, 2017 at 7:25 PM, Alexei Starovoitov <alexei.starovoi...@gmail.com> wrote: > On Sat, Feb 04, 2017 at 09:15:10AM -0800, Andy Lutomirski wrote: >> On Fri, Feb 3, 2017 at 5:22 PM, Alexei Starovoitov <a...@fb.com> wrote: >> > Note that all bpf programs types are global. >> >> I don't think this has a clear enough meaning to work with. In > > Please clarify what you mean. The quoted part says > "bpf programs are global". What is not "clear enough" there?
What does "bpf programs are global" mean? I am genuinely unable to figure out what you mean. Here are some example guesses of what you might mean: - BPF programs are compiled independently of a namespace. This is certainly true, but I don't think it matters. - You want BPF programs to affect everything on the system. But this doesn't seem right to be -- they only affect things in the relevant cgroup, so they're not global in that sense. - You want BPF programs to affect everything in their cgroup regardless of namespace. This does seem to be what you think, but it doesn't say *why*, which is the relevant bit. - The set of BPF program types and the verification rules are independent of cgroup and namespace. This is true, but I don't think it matters. That's all I came up with. So, I'll repeat: what does "bpf programs are global" mean? > >> I think that this patch plus a minor change to prevent installing >> cgroup+bpf programs if the installer isn't in the init netns + fs ns >> would work because it would allow new, migratable semantics to be >> added down the road to relax the restriction. > > Forcing installer to be in init netns is not acceptable to David > who added cgroup_sock in the first place. I'm not sure why > we have to discuss that bit in circles. > Because we're one week or so from 4.10 final, the 4.10-rc code is problematic even for ip vrf, and there isn't a clear solution yet. There are a bunch of requirements that seem to conflict, and something has to give. --Andy
