On 10/15/2015 05:21 PM, Kirill Tkhai wrote: > > > On 15.10.2015 14:15, Pavel Emelyanov wrote: >> >>> @@ -130,6 +131,34 @@ struct ve_struct { >>> #endif >>> }; >>> >>> +static inline struct ve_struct *get_exec_env(void) >>> +{ >>> + struct ve_struct *ve; >>> + >>> + if (++current->ve_attach_lock_depth > 1) >>> + return current->task_ve; >>> + >>> + rcu_read_lock(); >>> +again: >>> + ve = current->task_ve; >>> + read_lock(&ve->attach_lock); >>> + if (unlikely(current->task_ve != ve)) { >>> + read_unlock(&ve->attach_lock); >>> + goto again; >> >> Please, no. 3.10 kernel has task_work-s, ask the task you want to >> attach to ve to execute the work by moving itself into it and keep >> this small routine small and simple. > > cgroup_attach_task() is called under cgroup_mutex and threadgroup_lock(), > so we can't wait attaching task till it complete the task work (it may > execute any code; to be locking cgroup_mutex, for example).
I see. > Should we give a possibility (an interface) for userspace to get it know, > the task's finished ve changing? No. What are the places where get_exec_env() is still required? > >>> + } >>> + rcu_read_unlock(); >>> + >>> + return ve; >>> +} >>> + >> > . > _______________________________________________ Devel mailing list Devel@openvz.org https://lists.openvz.org/mailman/listinfo/devel