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] xen kernel crash at boot since 23598:b24018319772

To: "Keir Fraser" <keir.xen@xxxxxxxxx>
Subject: Re: [Xen-devel] xen kernel crash at boot since 23598:b24018319772
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Thu, 30 Jun 2011 16:49:56 +0100
Cc: Christoph Egger <Christoph.Egger@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
Delivery-date: Thu, 30 Jun 2011 08:50:53 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <CA3244F8.1D3D1%keir.xen@xxxxxxxxx>
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>
References: <4E0C8B9D020000780004B55A@xxxxxxxxxxxxxxxxxxxx> <CA3244F8.1D3D1%keir.xen@xxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> On 30.06.11 at 16:21, Keir Fraser <keir.xen@xxxxxxxxx> wrote:
> On 30/06/2011 13:43, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:
>> That's likely not the one, but rather 23573:584c2e5e03d9. And
>> indeed it seems like the assertion is a stale leftover from the
>> original non-RCU version of the patch. There are a few more
>> similar ones which may similarly be candidates fro removal.
>> Keir, what's your take on this?
> Not sure, pirq_spin_lock_irq_desc() has a comment about the event_lock
> preventing the PIRQ-IRQ mapping from changing under its feet. Why would the
> radix-tree patch change what code is protected by event_lock, anyway?

The whole function (including the comment) got added by that patch.
Hence either comment and assertion need fixing, or both need to
stay and calling code needs adjustment.

The RCU-ness, as I understand it, allows read accesses to the
PIRQ -> IRQ mapping to be done lockless, hence d->event_lock
needs to be held only if the intention is to alter the mapping
(which in particular isn't the case when unmasking an IRQ). Or
did I still not get my RCU thinking right?


Xen-devel mailing list