[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 bedoing?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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |