[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.