[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1456351368-786-17-git-send-email-tj@kernel.org>
Date: Wed, 24 Feb 2016 17:02:48 -0500
From: Tejun Heo <tj@...nel.org>
To: lizefan@...wei.com, hannes@...xchg.org
Cc: cgroups@...r.kernel.org, linux-kernel@...r.kernel.org,
kernel-team@...com, Tejun Heo <tj@...nel.org>
Subject: [PATCH 16/16] cgroup: allocate 2x cgrp_cset_links when setting up a new root
During prep, cgroup_setup_root() allocates cgrp_cset_links matching
the number of existing css_sets to later link the new root. This is
fine for now as the only operation which can happen inbetween is
rebind_subsystems() and rebinding of empty subsystems doesn't create
new css_sets.
However, while not yet allowed, with the recent reimplementation,
rebind_subsystems() can rebind subsystems with descendant csses and
thus can create new css_sets. This patch makes cgroup_setup_root()
allocate 2x of the existing css_sets so that later use of live
subsystem rebinding doesn't blow up.
Signed-off-by: Tejun Heo <tj@...nel.org>
---
kernel/cgroup.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 744e1c6..a44c123 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -1914,10 +1914,11 @@ static int cgroup_setup_root(struct cgroup_root *root, u16 ss_mask)
/*
* We're accessing css_set_count without locking css_set_lock here,
* but that's OK - it can only be increased by someone holding
- * cgroup_lock, and that's us. The worst that can happen is that we
- * have some link structures left over
+ * cgroup_lock, and that's us. Later rebinding may disable
+ * controllers on the default hierarchy and thus create new csets,
+ * which can't be more than the existing ones. Allocate 2x.
*/
- ret = allocate_cgrp_cset_links(css_set_count, &tmp_links);
+ ret = allocate_cgrp_cset_links(2 * css_set_count, &tmp_links);
if (ret)
goto cancel_ref;
--
2.5.0
Powered by blists - more mailing lists