Food for thought: could cgroup+bpf live in a cgroup v1-compatible controller?

* Food for thought: could cgroup+bpf live in a cgroup v1-compatible controller?
@ 2016-12-21 23:55 Andy Lutomirski
  0 siblings, 0 replies; only message in thread
From: Andy Lutomirski @ 2016-12-21 23:55 UTC (permalink / raw)
  To: Daniel Mack, Alexei Starovoitov, Mickaël Salaün,
	Kees Cook, Jann Horn, Tejun Heo, David Ahern, David S. Miller,
	Thomas Graf, Michael Kerrisk, Peter Zijlstra, Linux API,
	linux-kernel, Network Development, John Stultz,
	Eric W. Biederman

It seems to be that all of the new cgroup+bpf hooks and all of the
proposed networking-related ones that I'm aware of look at
sock_cgroup_ptr().  I'm wondering if this could me made cgroup v1
compatible?

As far as I can tell, this could be done with no changes at all to the
networking code and only minor changes to the cgroup code.
Specifically, there would be a new "socket" controller.  Its effect
would be that cgroup_sk_alloc() would load the current socket cgroup
instead of the current default cgroup, assuming that a socket cgroup
were installed.

Would this work?  I realize that there a moratorium on new fields in
sock (for good reasons), but this would require a new field or even
have a significant effect on the meaning of existing fields.  Instead
it would just change how the cgroup that's loaded into the existing
field is selected.

Would this be doable?  If so, would it be useful?

(If this were done, then presumably cgroup+lsm+bpf would consider
becoming a controller as well.)

--Andy

^ permalink raw reply	[flat|nested] only message in thread