lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 11 Nov 2008 12:10:39 +0900 From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com> To: Balbir Singh <balbir@...ux.vnet.ibm.com> Cc: linux-mm@...ck.org, YAMAMOTO Takashi <yamamoto@...inux.co.jp>, Paul Menage <menage@...gle.com>, lizf@...fujitsu.com, linux-kernel@...r.kernel.org, Nick Piggin <nickpiggin@...oo.com.au>, David Rientjes <rientjes@...gle.com>, Pavel Emelianov <xemul@...nvz.org>, Dhaval Giani <dhaval@...ux.vnet.ibm.com>, Andrew Morton <akpm@...ux-foundation.org> Subject: Re: [RFC][mm] [PATCH 4/4] Memory cgroup hierarchy feature selector (v2) On Sat, 08 Nov 2008 14:41:13 +0530 Balbir Singh <balbir@...ux.vnet.ibm.com> wrote: > > Don't enable multiple hierarchy support by default. This patch introduces > a features element that can be set to enable the nested depth hierarchy > feature. This feature can only be enabled when the cgroup for which the > feature this is enabled, has no children. > > Signed-off-by: Balbir Singh <balbir@...ux.vnet.ibm.com> > --- > IMHO, permission to this is not enough. I think following is sane way. == When parent->use_hierarchy==1. my->use_hierarchy must be "1" and cannot be tunrned to be "0" even if no children. When parent->use_hierarchy==0 my->use_hierarchy can be either of "0" or "1". this value can be chagned if we don't have children == Thanks, -Kame > mm/memcontrol.c | 43 ++++++++++++++++++++++++++++++++++++++++++- > 1 file changed, 42 insertions(+), 1 deletion(-) > > diff -puN mm/memcontrol.c~memcg-add-hierarchy-selector mm/memcontrol.c > --- linux-2.6.28-rc2/mm/memcontrol.c~memcg-add-hierarchy-selector 2008-11-08 14:09:33.000000000 +0530 > +++ linux-2.6.28-rc2-balbir/mm/memcontrol.c 2008-11-08 14:10:53.000000000 +0530 > @@ -137,6 +137,11 @@ struct mem_cgroup { > * reclaimed from. > */ > struct mem_cgroup *last_scanned_child; > + /* > + * Should the accounting and control be hierarchical, per subtree? > + */ > + unsigned long use_hierarchy; > + > }; > static struct mem_cgroup init_mem_cgroup; > > @@ -1079,6 +1084,33 @@ out: > return ret; > } > > +static u64 mem_cgroup_hierarchy_read(struct cgroup *cont, struct cftype *cft) > +{ > + return mem_cgroup_from_cont(cont)->use_hierarchy; > +} > + > +static int mem_cgroup_hierarchy_write(struct cgroup *cont, struct cftype *cft, > + u64 val) > +{ > + int retval = 0; > + struct mem_cgroup *mem = mem_cgroup_from_cont(cont); > + > + if (val == 1) { > + if (list_empty(&cont->children)) > + mem->use_hierarchy = val; > + else > + retval = -EBUSY; > + } else if (val == 0) { > + if (list_empty(&cont->children)) > + mem->use_hierarchy = val; > + else > + retval = -EBUSY; > + } else > + retval = -EINVAL; > + > + return retval; > +} > + > static u64 mem_cgroup_read(struct cgroup *cont, struct cftype *cft) > { > return res_counter_read_u64(&mem_cgroup_from_cont(cont)->res, > @@ -1213,6 +1245,11 @@ static struct cftype mem_cgroup_files[] > .name = "stat", > .read_map = mem_control_stat_show, > }, > + { > + .name = "use_hierarchy", > + .write_u64 = mem_cgroup_hierarchy_write, > + .read_u64 = mem_cgroup_hierarchy_read, > + }, > }; > > static int alloc_mem_cgroup_per_zone_info(struct mem_cgroup *mem, int node) > @@ -1289,9 +1326,13 @@ mem_cgroup_create(struct cgroup_subsys * > parent = mem_cgroup_from_cont(cont->parent); > if (!mem) > return ERR_PTR(-ENOMEM); > + mem->use_hierarchy = parent->use_hierarchy; > } > > - res_counter_init(&mem->res, parent ? &parent->res : NULL); > + if (parent && parent->use_hierarchy) > + res_counter_init(&mem->res, &parent->res); > + else > + res_counter_init(&mem->res, NULL); > > for_each_node_state(node, N_POSSIBLE) > if (alloc_mem_cgroup_per_zone_info(mem, node)) > _ > > -- > Balbir > -- 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