linux-kernel - Re: Async resume patch (was: Re: [GIT PULL] PM updates for 2.6.33)

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: <Pine.LNX.4.44L0.0912091356200.4120-100000@iolanthe.rowland.org>
Date:	Wed, 9 Dec 2009 14:06:46 -0500 (EST)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
cc:	"Rafael J. Wysocki" <rjw@...k.pl>, Zhang Rui <rui.zhang@...el.com>,
	LKML <linux-kernel@...r.kernel.org>,
	ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
	pm list <linux-pm@...ts.linux-foundation.org>
Subject: Re: Async resume patch (was: Re: [GIT PULL] PM updates for 2.6.33)

On Tue, 8 Dec 2009, Linus Torvalds wrote:

> > Wait a second.  Are you saying that with code like this:
> > 
> > 	if (x == 1)
> > 		y = 5;
> > 
> > the CPU may write to y before it has finished reading the value of x?  

> > And this write is visible to other CPUs, so that if x was initially 0
> > and a second CPU sets x to 1, the second CPU may see y == 5 before it
> > executes the write to x (whatever that may mean)?
> 
> Well, yes and no. CPU1 above won't release the '5' until it has confirmed 
> the '1' (even if it does so by reading it late). but assuming the other 
> CPU also does speculation, then yes, the situation you describe could 
> happen. If the other CPU does
> 
> 		z = y;
> 		x = 1;
> 
> then it's certainly possible that 'z' contains 5 at the end (even if both 
> x and y started out zero). Because now the read of 'y' on that other CPU 
> might be delayed, and the write of 'x' goes ahead, CPU1 sees the 1, and 
> commits its write of 5, sp when CPU2 gets the cacheline, z will now 
> contain 5.

That could be attributed to reordering on CPU2, so let's take CPU2's
peculiarities out of the picture (initially everything is set to 0):

	CPU1			CPU2
	----			----
	if (x == 1)		z = y;
		y = 5;		mb();
				x = 1;

This gets at the heart of the question: Can a write move up past a
control dependency?  Similar questions apply to the two types of data 
dependency:

	CPU1			CPU2
	----			----
	y = x + 4;		z = y;
				mb();
				x = 1;

(Initially p points to x, not y):

	CPU1			CPU2
	----			----
	*p = 5;			z = y;
				mb();
				p = &y;

Can z end up equal to 5 in any of these examples?

Alan Stern

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