Re: [Xen-devel] Re: First post-xenbus-change USB patch

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

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