More Web Proxy on the site http://driver.im/
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <496D524E.6050706@cn.fujitsu.com>
Date: Wed, 14 Jan 2009 10:47:42 +0800
From: Li Zefan <lizf@...fujitsu.com>
To: Paul Menage <menage@...gle.com>
CC: Grzegorz Nosek <root@...aldomain.pl>, containers@...ts.osdl.org,
netdev@...r.kernel.org
Subject: Re: [Devel] Re: [RFC][PATCH] IP address restricting cgroup subsystem
> That would be possible, but I'm not sure that extending
> hierarchy_mutex across all the create calls is a good idea - it's
> meant to be very lightweight.
>
agree
> OK, an alternative way to avoid cgroup_lock() is for the
> spinlock-protected state in ipcgroup to be the address and the count
> of active children.
>
This works. But:
- we put extra burden on subsystem developers.
- hierarchy_mutex can't do what we expect, and it's a bit subtle.
- there won't be performance problem or potential lock issue to use
cgroup_mutex in subsys' simple write functions, so I don't think
we have to avoid cgroup_mutex here.
In memcg, both mem_cgroup_hierarchy_write() and mem_cgroup_swappiness_write()
check cgrp->children list, similar to ipv4_write() here. And I'm going
to fix swappiness_write() for it doesn't hold cgroup_lock(), but if
avoiding cgroup_lock() is the direction, then I have to use this
alternative way you sugguested.
> create() does:
>
> lock parent
> css->addr = parent->addr
> parent->child_count++;
> unlock parent
>
> and write does:
>
> lock css
> if (!css->child_count) {
> css->addr = new_addr
> } else {
> report error;
> }
> unlock css
>
> Paul
>
>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists