David Rientjes wrote:
> On Thu, 30 Dec 2010, Li Zefan wrote:
>
>> That's what we did for cpu masks :). See commit
>> 2341d1b6598c7146d64a5050b53a72a5a819617f.
>>
>> I made a patchset to remove on stack cpu masks.
>>
>> What I meant is we don't have to allocate nodemasks in cpuset_sprintf_memlist().
>> This is sufficient:
>>
>> diff --git a/kernel/cpuset.c b/kernel/cpuset.c
>> index 4349935..a159612 100644
>> --- a/kernel/cpuset.c
>> +++ b/kernel/cpuset.c
>> @@ -1620,20 +1620,12 @@ static int cpuset_sprintf_cpulist(char *page, struct cpu
>>
>> static int cpuset_sprintf_memlist(char *page, struct cpuset *cs)
>> {
>> - NODEMASK_ALLOC(nodemask_t, mask, GFP_KERNEL);
>> int retval;
>>
>> - if (mask == NULL)
>> - return -ENOMEM;
>> -
>> mutex_lock(&callback_mutex);
>> - *mask = cs->mems_allowed;
>> + retval = nodelist_scnprintf(page, PAGE_SIZE, cs->mems_allowed);
>> mutex_unlock(&callback_mutex);
>>
>> - retval = nodelist_scnprintf(page, PAGE_SIZE, *mask);
>> -
>> - NODEMASK_FREE(mask);
>> -
>> return retval;
>> }
>>
>
> This needs to be done with cgroup_lock() instead of callback_mutex since
> the post_clone() callback will store to cs->mems_allowed on
> cgroup_clone().
>
Then cpuset_post_clone() breaks the lock rule:
* A task must hold both mutexes to modify cpusets...
...
* If a task is only holding callback_mutex, then it has read-only
* access to cpusets.
But that's Ok, because cgroup_clone() is called during the creation of
the new cgroup, so no one can access the cpuset at that time.
_______________________________________________
Containers mailing list
Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/containers
