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

Re: [Xen-devel] locking in drivers/xen/xen-pciback/passthrough.c:__xen_p

To: Jan Beulich <JBeulich@xxxxxxxx>
Subject: Re: [Xen-devel] locking in drivers/xen/xen-pciback/passthrough.c:__xen_pcibk_publish_pci_roots()
From: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Date: Fri, 16 Sep 2011 13:27:08 -0400
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 16 Sep 2011 10:28:18 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4E73746702000078000568A0@xxxxxxxxxxxxxxxxxxxx>
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: <4E73746702000078000568A0@xxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.21 (2010-09-15)
On Fri, Sep 16, 2011 at 03:08:07PM +0100, Jan Beulich wrote:
> Konrad,
> 
> this function, before calling the passed in callback, drops the lock it
> acquired at the beginning of the function, and re-acquires it after the
> callback returned. It also uses list_for_each_entry_safe() in an
> apparent attempt to deal with races here. However, I'm getting the
> impression that this wouldn't really work (as the construct really isn't
> meant for this case): If in the meantime the successor element got
> removed from the list, the loop continuation would access data that
> may already have got freed.
> 
> I see two possible solutions: Either after re-acquiring the lock the
> function checks whether the current object is sill on the list, starting
> over if not found (xen_pcibk_publish_pci_root() makes sure a
> device doesn't get published twice), or (if so possible) the lock gets
> converted to a mutex (which should be safe to be held across the
> callback invocation).
> 
> What are your thoughts here?

I think mutexs would work here best. We don't any of these operations in
an IRQ interrupt context, so we are OK to be put to sleep.

I think there is some room in improvement in some of the other Xen code
in this regard - where we use spinlocks and could use a mechanism
that is OK to go to sleep.


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

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