[Devel] [PATCH rh7 1/3] ve: Attach a ve cgroup from task_work
Vladimir Davydov
vdavydov at virtuozzo.com
Tue Oct 27 09:13:27 PDT 2015
On Fri, Oct 16, 2015 at 07:24:49PM +0300, Kirill Tkhai wrote:
...
> @@ -733,6 +742,13 @@ static int ve_can_attach(struct cgroup *cg, struct cgroup_taskset *tset)
> }
> }
>
> + cgroup_taskset_for_each(task, cg, tset) {
> + /* Attaching is in process */
> + if (task->task_ve_work.func != NULL)
> + return -EAGAIN;
Failing write to cgroup.procs with EAGAIN looks unexpected. For sure,
nobody will retry.
> + }
> + smp_mb(); /* Pairs with smp_mb() in ve_attach_work() */
> +
> return 0;
> }
>
> @@ -753,7 +769,8 @@ static void ve_attach(struct cgroup *cg, struct cgroup_taskset *tset)
> /* Leave parent exec domain */
> task->parent_exec_id--;
>
> - task->task_ve = ve;
> + init_task_work(&task->task_ve_work, ve_attach_work);
Why do you need to keep the work on task_struct? It's already huge, so
let's please try not to make it even bigger. I don't see any reason why
kmalloc-ing a task_work wouldn't suffice in this case. Moreover, AFAICS
it would liberate us from the necessity to use memory barriers and allow
us to avoid EAGAIN failures.
Hell, I placed ub's cgroup_attach_work in task_struct either, what a
mess...
Besides, I don't see you handle a race with fork (see ub_cgroup_fork).
Why?
> + task_work_add(task, &task->task_ve_work, true);
> }
> }
>
>
More information about the Devel
mailing list