xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Keir Fraser <keir.xen@gmail.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>
Subject: Re: Re: [PATCH] Fix cpu offline bug
Date: Tue, 08 Mar 2011 15:36:43 +0000	[thread overview]
Message-ID: <C99BFD8B.14500%keir.xen@gmail.com> (raw)
In-Reply-To: <4D760F8002000078000351E8@vpn.id2.novell.com>

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
> 

  reply	other threads:[~2011-03-08 15:36 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-04 10:22 [PATCH] Fix cpu offline bug Liu, Jinsong
2011-03-04 10:49 ` Keir Fraser
2011-03-08  8:52   ` Jan Beulich
2011-03-08  9:47     ` Liu, Jinsong
2011-03-08 10:14       ` Jan Beulich
2011-03-08 15:36         ` Keir Fraser [this message]
2011-03-05 11:40 ` Keir Fraser
2011-03-05 15:10   ` Liu, Jinsong
2011-03-05 15:57     ` Keir Fraser

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=C99BFD8B.14500%keir.xen@gmail.com \
    --to=keir.xen@gmail.com \
    --cc=JBeulich@novell.com \
    --cc=jinsong.liu@intel.com \
    --cc=xen-devel@lists.xensource.com \
    --cc=xin.li@intel.com \
    --cc=yunhong.jiang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).