Re: [patch for-3.2-rc3] cpusets: stall when updating mems_allowedfor mempolicy or disjoint nodemask

[Miao Xie]

On Thu, 17 Nov 2011 13:33:14 -0800 (pst), David Rientjes wrote:
> On Thu, 17 Nov 2011, Miao Xie wrote:
> 
>> Oh~, David
>>
>> I find these is another problem, please take account of the following case:
>>
>>   2-3 -> 1-2 -> 0-1
>>
>> the user change mems_allowed twice continuously, the task may see the empty
>> mems_allowed.
>>
>> So, it is still dangerous.
>>
> 
> With this patch, we're protected by task_lock(tsk) to determine whether we 
> want to take the exception, i.e. whether need_loop is false, and the 
> setting of tsk->mems_allowed.  So this would see the nodemask change at 
> the individual steps from 2-3 -> 1-2 -> 0-1, not some inconsistent state 
> in between or directly from 2-3 -> 0-1.  The only time we don't hold 
> task_lock(tsk) to change tsk->mems_allowed is when tsk == current and in 
> that case we're not concerned about intermediate reads to its own nodemask 
> while storing to a mask where MAX_NUMNODES > BITS_PER_LONG.
> 
> Thus, there's no problem here with regard to such behavior if we exclude 
> mempolicies, which this patch does.
> 

No.
When the task does memory allocation, it access its mems_allowed without
task_lock(tsk), and it may be blocked after it check 0-1 bits. And then, the
user changes mems_allowed twice continuously(2-3(initial state) -> 1-2 -> 0-1),
After that, the task is woke up and it see the empty mems_allowed.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/