[lkml]   [2013]   [Dec]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: cgroup filter on physics interface can't control container
hello guys,

I said before "we can save sk_classid before skb_scrub_packet and
restore it after that" since skb->sk had been freed in
skb_scrub_packet(), so it is not reasonable. yes?

I have another idea.
commit:f84517253(cls_cgroup: Store classid in struct sock) introduces
sk_classid and put it in skb->sk pointer. can we put sk_classid form
struct sock to struct sk_buff? then sk_classid will not be affected
by dev_forward_skb()->skb_scrub_packet() ?

any comment are welcome!


On 2013/12/12 20:18, Libo Chen wrote:
> ping...
> On 2013/12/9 10:32, Libo Chen wrote:
>> hello network hackers,
>> A linux container was builded with veth pair(veth0 inside container, veth1 outside container),
>> the config as below:
>> = veth
>> = up
>> = br0 // base on eth0
>> = eth0
>> =
>> then I use tc command with cgroup filter on veth0, it works well. But when setting on eth0, it doesn`t work.
>> The reason is dev_forward_skb() in veth_xmit will call skb_scrub_packet and clean all information including skb->sk
>> in the skb, so if cls_cgroup_classify is working in serving softirq state, it will return failer, see below:
>> if (in_serving_softirq()) {
>> /* If there is an sk_classid we'll use that. */
>> if (!skb->sk)
>> return -1;
>> classid = skb->sk->sk_classid;
>> }
>> Qdisc with cgroup filter on physics interface can not control a container network, it is disappointed.
>> we can save sk_classid before skb_scrub_packet and restore it after that. Is it reasonable? or any way to achieve this?
>> thanks,
>> Libo

 \ /
  Last update: 2013-12-18 12:21    [W:0.266 / U:0.432 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site