On Thu, 17 Nov 2011, Andrew Morton wrote: > Nothing in this changelog makes me understand why you think we need this > change in 3.2. What are the user-visible effects of this change? > Kernels where MAX_NUMNODES > BITS_PER_LONG may temporarily see an empty nodemask in a tsk's mempolicy if its previous nodemask is remapped onto a new set of allowed cpuset nodes where the two nodemasks, as a result of the remap, are now disjoint. This fix is a bandaid so that we never optimize the stores to tsk->mems_allowed because they intersect if tsk also has an existing mempolicy, so that prevents the possibility of seeing an empty nodemask during rebind. For 3.3, I'd like to ensure that remapping any mempolicy's nodemask will never result in an empty nodemask. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. 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@xxxxxxxxx";> email@xxxxxxxxx </a>