[Devel] [RFC] Fix get_exec_env() races

Pavel Emelyanov xemul at parallels.com
Thu Oct 15 07:23:43 PDT 2015


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;
>>> +}
>>> +
>>
> .
> 




More information about the Devel mailing list