Re: [PATCH 4/5] sock, cgroup: add sock->sk_cgroup

From: Daniel Borkmann
Date: Tue Nov 17 2015 - 16:46:57 EST

Hi Tejun,

On 11/17/2015 08:40 PM, Tejun Heo wrote:
While it is possible to solve these issues from controller side by
implementing hierarchical allowable ranges in both controllers, it
would involve quite a bit of complexity in the controllers and further
obfuscate network configuration as it becomes even more difficult to
tell what's actually being configured looking from the network side.
While not much can be done for v1 at this point, as membership
handling is sane on cgroup v2, it'd be better to make cgroup matching
behave like other network matches and classifiers than introducing
further complications.

In preparation, this patch adds sock->sk_cgroup which points to the
associated cgroup. A sock is associated on creation and stays
associated to the same cgroup until freed; unfortunately, this ends up
adding another cgroup field to struct sock on top of sk_cgrp_prioidx
and sk_classid. I tried to think of a way to somehow overload the
existing fields but couldn't come up with a reasonable one. For the
longer term, the fields can be rearranged so that disabling prio and
cls controllers reduce the size of the struct.

Do you see a way forward where the new behavior could be enabled f.e.
as an extra mount option (that long-term would be made default, while
deprecating the current behavior) on net_cls et al? There are various
more users at least on the net_cls side (nft and tc as well). Would be
really great, if sk_cgroup could abstract that somehow away for all of
them w/o adding a second version to all users.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at