After waiting for a child to finish offline,
cgroup_subtree_control_write() jumps up to retry from after the input
parsing and active protection breaking. This retry makes the
scheduled locking update more difficult. Let's simplify it by
returning with restart_syscall() for retries.
Signed-off-by: Tejun Heo <t...@kernel.org>
---
kernel/cgroup.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 9066fe9..3ced79a 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -2535,7 +2535,7 @@ out_finish:
static int cgroup_subtree_control_write(struct cgroup_subsys_state *dummy_css,
struct cftype *cft, char *buffer)
{
- unsigned int enable_req = 0, disable_req = 0, enable, disable;
+ unsigned int enable = 0, disable = 0;
struct cgroup *cgrp = dummy_css->cgroup, *child;
struct cgroup_subsys *ss;
char *tok, *p;
@@ -2552,11 +2552,11 @@ static int cgroup_subtree_control_write(struct
cgroup_subsys_state *dummy_css,
continue;
if (*tok == '+') {
- enable_req |= 1 << ssid;
- disable_req &= ~(1 << ssid);
+ enable |= 1 << ssid;
+ disable &= ~(1 << ssid);
} else if (*tok == '-') {
- disable_req |= 1 << ssid;
- enable_req &= ~(1 << ssid);
+ disable |= 1 << ssid;
+ enable &= ~(1 << ssid);
} else {
return -EINVAL;
}
@@ -2574,9 +2574,6 @@ static int cgroup_subtree_control_write(struct
cgroup_subsys_state *dummy_css,
*/
cgroup_get(cgrp);
kernfs_break_active_protection(cgrp->control_kn);
-retry:
- enable = enable_req;
- disable = disable_req;
mutex_lock(&cgroup_tree_mutex);
@@ -2606,7 +2603,9 @@ retry:
schedule();
finish_wait(&child->offline_waitq, &wait);
cgroup_put(child);
- goto retry;
+
+ ret = restart_syscall();
+ goto out_unbreak;
}
/* unavailable or not enabled on the parent? */
@@ -2690,6 +2689,7 @@ out_unlock:
mutex_unlock(&cgroup_mutex);
out_unlock_tree:
mutex_unlock(&cgroup_tree_mutex);
+out_unbreak:
kernfs_unbreak_active_protection(cgrp->control_kn);
cgroup_put(cgrp);
return ret;
--
1.9.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
