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] [XEN][ACM] fix missing spin_unlock

To: Stefan Berger <stefanb@xxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] Re: [PATCH] [XEN][ACM] fix missing spin_unlock
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Mon, 26 Feb 2007 23:20:38 +0000
Cc: sailer@xxxxxxxxxx
Delivery-date: Mon, 26 Feb 2007 15:22:48 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <1172519828.9051.11.camel@xxxxxxxxxxxxxxxxxxxxx>
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcdZ/Llf9/eObMXvEdu1nwAWy6hiGQ==
Thread-topic: [PATCH] [XEN][ACM] fix missing spin_unlock
User-agent: Microsoft-Entourage/11.3.3.061214
On 26/2/07 19:57, "Stefan Berger" <stefanb@xxxxxxxxxx> wrote:

>  I have a question regarding the event channel data structure. It looks
> like a stale entry is in the event channel array indicating that a event
> channel at a given port has a certain remote domain as target. However,
> that domain does not exist anymore and therefore the code section where
> I add the spin_unlock() call gets triggered now. Could this be a bug in
> the domain-cleanup code?
> 
>   I can trigger this problem when running the xm-test suite with ACM
> compiled into Xen. After 159 domains have been created, which happens to
> be during the list tests, the stale port entry shows up and remains. The
> list tests when run after a reboot do not trigger this, though.

When one end of a fully-bound interdomain event channel is closed, the
remote port enters state ECS_UNBOUND. At this point it still refers to the
remote domain by domid, even if the remote domain subsequently dies. In fact
this is exactly the state that all currently-interdomain-bound remote ports
will immediately enter when a domain is destroyed. It's safe and expected.
Since an ACM check will happen when moving from state ECS_UNBOUND to
ECS_INTERDOMAIN you get the chance to check credentials are okay and hence
deal with the case that the domid gets reused by a domain who should not be
allowed to communicate to the ECS_UNBOUND port.

 -- Keir



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

<Prev in Thread] Current Thread [Next in Thread>