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

[David Rientjes <rientjes@google.com>]

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.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>