| |
|
 |
|
 |
|
|
|
| |
|
|
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
|
|
|
| |
|
Home