This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] Re: [PATCH] Fix cpu offline bug

To: Jan Beulich <JBeulich@xxxxxxxxxx>, Jinsong Liu <jinsong.liu@xxxxxxxxx>
Subject: Re: [Xen-devel] Re: [PATCH] Fix cpu offline bug
From: Keir Fraser <keir.xen@xxxxxxxxx>
Date: Tue, 08 Mar 2011 15:36:43 +0000
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Yunhong Jiang <yunhong.jiang@xxxxxxxxx>, Xin Li <xin.li@xxxxxxxxx>
Delivery-date: Tue, 08 Mar 2011 07:37:37 -0800
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:user-agent:date:subject:from:to:cc:message-id :thread-topic:thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=6Ks6ng2k0gW2+lKTFnimBqOP0RUfr0PLZlLDw3H6xW0=; b=emMUQrdWMo74b6waXHrZ9k020ZWrLGg1XikqYNjRLkS0dCAS3+YkZOKlekIzVcdD13 YruEtzfW2OTK6hAQmot6NplMoWe0lSc7vmL6fZytMOXAfRM7j7XXbuCeczk82sf4UkcA tJNpP/S4lSPx63rOAVYZ9ynQcgEUNc4LXb70Y=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; b=RrtToKc2L/JE0zpY5gGkkGhg6vaYSHFmqScd2+A6XOBT6JCF3xjbnpm63MfWBbQ9j4 4phkboVw+pzfAC/v1hT7Ns/OQUQkHzZH6bmUIERSDJ2m5bTwatvqIjgmFFxw7CCGt4gN tX3JScYJ5Ikdpupiq8DTkGfmmtb/0MJPsWxig=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4D760F8002000078000351E8@xxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcvdpqAREaFh7CFgBEOZv7lEbF0mcw==
Thread-topic: [Xen-devel] Re: [PATCH] Fix cpu offline bug
User-agent: Microsoft-Entourage/
On 08/03/2011 10:14, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:

>>>> On 08.03.11 at 10:47, "Liu, Jinsong" <jinsong.liu@xxxxxxxxx> 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

Xen-devel mailing list