From mboxrd@z Thu Jan  1 00:00:00 1970
From: Keir Fraser <keir.xen@gmail.com>
Subject: Re: Re: [PATCH] Fix cpu offline bug
Date: Tue, 08 Mar 2011 15:36:43 +0000
Message-ID: <C99BFD8B.14500%keir.xen@gmail.com>
References: <4D760F8002000078000351E8@vpn.id2.novell.com>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xensource.com>
In-Reply-To: <4D760F8002000078000351E8@vpn.id2.novell.com>
List-Unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com
To: Jan Beulich <JBeulich@novell.com>, Jinsong Liu <jinsong.liu@intel.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>, Yunhong Jiang <yunhong.jiang@intel.com>, Xin Li <xin.li@intel.com>
List-Id: xen-devel@lists.xenproject.org

On 08/03/2011 10:14, "Jan Beulich" <JBeulich@novell.com> wrote:

>>>> On 08.03.11 at 10:47, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:
>> Jan, I'm not quite clear your meaning.
>> Why and where need to insert barrier, or volatile cpu_state?
>  
>      while ( (seen_state = cpu_state) != CPU_STATE_DEAD )
>      {
> +        barrier();
>          BUG_ON(seen_state != CPU_STATE_DYING);
>          mdelay(100);
>          cpu_relax();
> 
> Without this, the compiler is free to eliminate "seen_state" in favor
> of reading "cpu_state" twice (irrespective of the optimizer very
> likely trying to do exactly the opposite).

Haha, you're getting paranoid Jan! What you describe is impossible -- there
is no way that C semantics allow a local variable's value to change after it
has affected program behaviour (if it hasn't escaped local scope by having
its address taken for example). If that could happen then we'd have plenty
of other code that doesn't work properly either, I'm sure.

In this case, if a second read from cpu_state did occur then we could end up
observing seen_state==CPU_STATE_DEAD, in a code block that is predicated on
this not being true!

 -- Keir

> Jan
>