linux-kernel - Re: [regression] cpuset,mm: update tasks' mems

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]

Date:	Mon, 22 Feb 2010 23:12:22 +1100
From:	Nick Piggin <npiggin@...e.de>
To:	David Rientjes <rientjes@...gle.com>
Cc:	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	Miao Xie <miaox@...fujitsu.com>,
	Lee Schermerhorn <lee.schermerhorn@...com>
Subject: Re: [regression] cpuset,mm: update tasks' mems_allowed in time
 (58568d2)

On Fri, Feb 19, 2010 at 02:06:45AM -0800, David Rientjes wrote:
> On Fri, 19 Feb 2010, Nick Piggin wrote:
> > But it doesn't matter if stores are done under lock, if the loads are
> > not. masks can be multiple words, so there isn't any ordering between
> > reading half and old mask and half a new one that results in an invalid
> > state. AFAIKS.
> > 
> 
> It doesn't matter for MAX_NUMNODES > BITS_PER_LONG because 
> task->mems_alllowed only gets updated via cpuset_change_task_nodemask() 
> where the added nodes are set and then the removed nodes are cleared.  The 
> side effect of this lockless access to task->mems_allowed means we may 
> have a small race between
> 
> 	nodes_or(tsk->mems_allowed, tsk->mems_allowed, *newmems);
> 
> 		and
> 
> 	tsk->mems_allowed = *newmems;
> 
> but the penalty is that we get an allocation on a removed node, which 
> isn't a big deal, especially since it was previously allowed.

If you have a concurrent reader without any synchronisation, then what
stops it from loading a word of the mask before stores to add the new
nodes and then loading another word of the mask after the stores to
remove the old nodes? (which can give an empty mask).

--
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/