Re: tun: Use netif_receive_skb instead of netif_rx

David Miller
2010-05-21T05:49:35Z

From: Neil Horman <nhorman@tuxdriver.com>
Date: Thu, 20 May 2010 20:39:39 -0400

> On Fri, May 21, 2010 at 09:16:30AM +1000, Herbert Xu wrote:
>> On Thu, May 20, 2010 at 01:29:18PM -0400, Neil Horman wrote:
>> >
>> > So, I'm testing this patch out now, and unfotunately it doesn't seem to be
>> > working. Every frame seems to be holding a classid of 0. Trying to figure out
>> > why now.
>>
>> Not very surprising since tun.c doesn't go through the normal
>> socket interface. I'll send a additional patch for that.
>>
> I don't think thats it. I think its a chicken and egg situation. I think the
> problem is that tasks can't be assigned to cgroups until their created, and in
> that time a sock can be created. Its a natural race. If you create a socket
> before you assign it to a cgroup, that socket retains a classid of zero. I'm
> going to try modify the patch to update sockets owned by tasks when the cgroup
> is assigned.

Neil, you must not be using Herbert's most recent patch.

Either that or you haven't even read it.

Herbert's most recent patch doesn't create this chicken and egg
problem you mention because it explicitly watches for cgroupid changes
at all socket I/O operations including sendmsg() and sendmsg(). And
if it sees a different cgroupid at a socket I/O call, it updates the
cgroupid value in the socket.

So you very much can change the cgroup of the process mid-socket
ownership and it will work.

The only problem is, as Herbert stated, tun. Because it does it's
networking I/O directly by calling netif_receive_skb() so it won't
hit any of Herbert's cgroup check points.