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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.00.1111181549460.24487@chino.kir.corp.google.com>
Date:	Fri, 18 Nov 2011 15:53:00 -0800 (PST)
From:	David Rientjes <rientjes@...gle.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Miao Xie <miaox@...fujitsu.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Paul Menage <paul@...lmenage.org>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [patch v2 for-3.2-rc3] cpusets: stall when updating mems_allowed
 for mempolicy or disjoint nodemask

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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/