[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <166fe7950809101556q61cb7e30m2d5e758304618f61@mail.gmail.com>
Date: Wed, 10 Sep 2008 15:56:55 -0700
From: "Ranjit Manomohan" <ranjitm@...gle.com>
To: "Thomas Graf" <tgraf@...g.ch>
Cc: davem@...emloft.net, akpm@...ux-foundation.org, kaber@...sh.net,
lizf@...fujitsu.com, menage@...gle.com,
linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH 1/2] Traffic control cgroups subsystem
On Wed, Sep 10, 2008 at 3:01 PM, Thomas Graf <tgraf@...g.ch> wrote:
> * Ranjit Manomohan <ranjitm@...gle.com> 2008-09-10 10:42
>> +void cgroup_tc_set_sock_classid(struct sock *sk)
>> +{
>> + if (sk)
>> + sk->sk_cgroup_classid = cgroup_tc_classid(current);
>> +}
>> +
>> @@ -1170,6 +1171,8 @@ static int __sock_create(struct net *net, int family, int type, int protocol,
>> if (err < 0)
>> goto out_module_put;
>>
>> + cgroup_tc_set_sock_classid(sock->sk);
>> +
>> /*
>> * Now to bump the refcnt of the [loadable] module that owns this
>> * socket at sock_release time we decrement its refcnt.
>> @@ -1444,6 +1447,8 @@ asmlinkage long sys_accept(int fd, struct sockaddr __user *upeer_sockaddr,
>> if (err < 0)
>> goto out_fd;
>>
>> + cgroup_tc_set_sock_classid(newsock->sk);
>> +
>> if (upeer_sockaddr) {
>> if (newsock->ops->getname(newsock, (struct sockaddr *)address,
>> &len, 2) < 0) {
>
> The big disadvantage of this method is that it does not allow to change
> the classid for sockets which already exist. It inherits the classid
> at socket creation time and then sticks to it. So if you want to follow
> this approach I'd suggest to at least store a reference to the cgroup
> state and reference count it properly.
>
I had considered adding support for moving tasks between cgroups by
going through all the open fds of the task and updating the sockets
(in the cgroup attach method). It is a very heavy weight operation and
not considered a common use case (and even undesirable at times) so I
dropped the idea. I can add it back in if it is considered essential.
> As for the locking that you mentioned in the other thread. IMHO it is
> not possible to lookup a socket without taking at least one lock, but
> I might be wrong there. Actually I think it will take even more locks
> as different locks are used to f.e. protect listening and established
> tcp sockets.
That is correct for ingress, for egress the sk is already available in
the skb so should be fine.
-Thanks,
Ranjit
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists