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] Re: First post-xenbus-change USB patch


On 15 Nov 2005, at 16:12, Keir Fraser wrote:

Yes, we really need to address that one.  The code says

        /* Flush any currently-executing callback, unless we are it. :-) */

(IIRC, that's the deadlock point that Rusty highlighted) but I don't really know what this means. Can you shed some light here on what we ought to be
doing?

I'd love to see the xenwatch_mutex disappear -- it could well be involved in a deadlock situation. It is only used to ensure that an unregistered watch is not still executing when unregister_xenbus_watch() returns, but that is kind of important if e.g., module code is about to get blown away. :-)

I'll have a think about it...

Actually I now remember that this is a hard one to avoid. Callers will often be interested in unregister being synchronous (so they can safely unload module code, free the xenbus_watch, or whatever) but if they ever call unregister_xenbus_watch() with a resource held (e.g., a mutex) that the watch callback also may acquire, then we have possibility of a deadlock. And there are various slightly hidden mutexes in sysfs.... :-(

 -- Keir


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

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