WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: [PATCH] Fix cpu hotplug bug of mtrr update inconsistency

To: "Liu, Jinsong" <jinsong.liu@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] Re: [PATCH] Fix cpu hotplug bug of mtrr update inconsistency
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Tue, 1 Jun 2010 10:18:36 +0100
Cc:
Delivery-date: Tue, 01 Jun 2010 02:19:59 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <BC00F5384FCFC9499AF06F92E8B78A9E062ADFC37F@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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: AcsBY4JCH46cmVkHTAyPKp/cXkDMoQAB+ehD
Thread-topic: [PATCH] Fix cpu hotplug bug of mtrr update inconsistency
User-agent: Microsoft-Entourage/12.24.0.100205
On 01/06/2010 09:22, "Liu, Jinsong" <jinsong.liu@xxxxxxxxx> wrote:

> Fix cpu hotplug bug of mtrr update inconsistency
> 
> c/s 20021 changes some mtrr update logic.
> A bug is, when a cpu hot-add and then mtrr update, another cpu hot-add may
> break cpu_online_map
> consistency and result in deadlock.
> This patch is used to fix the bug. It move 'mtrr_ap_init' back to bp-ap sync
> stage protected by
> CPU_STATE_CALLOUT and CPU_STATE_CALLIN, and then keep consistency.

This is an old bug, rather than introduced by my changes, right?

I suggest we leave the call where it is, and fix set_mtrr() to not race CPUs
coming online. It is called elsewhere other than mtrr_ap_init() after all.
Also if you call mtrr_ap_init() before being in cpu_online_map, you then
race further MTRR changes:
 - CPU X calls mtrr_ap_init()
 - CPU Y calls set_mtrr() to actually change an MTRR.
 - CPU X adds itself to cpu_online_map
 - Aiee, CPU X is missing Y's update

I'll make a patch.

By the way, our MTRR subsystem is really pants! :-/

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel