[Devel] [RFC] Fix get_exec_env() races

[Kirill Tkhai]

On 15.10.2015 17:23, Pavel Emelyanov wrote:
> 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?

Ok.

We use it from time to time

$ git grep get_exec_env | grep -v ve_is_super | wc -l
71

>>  
>>>> +	}
>>>> +	rcu_read_unlock();
>>>> +
>>>> +	return ve;
>>>> +}
>>>> +
>>>
>> .
>>
>