On Thu, Jan 15, 2009 at 05:29:12PM +0000, Richard W.M. Jones wrote: > On Tue, Jan 13, 2009 at 05:44:21PM +0000, Daniel P. Berrange wrote: > > This patch makes the various Xen drivers threadsafe by adding a > > mutex lock on the xenUnifiedPrivatePtr object. The XenD driver > > does not really need much locking, since it usually just calls > > out to XenD. Likewise the Xen driver just makes hypercalls. Locks > > are needed for libxenstore access, and the xm/inotify drivers > > since they have shared state > > > > src/proxy_internal.c | 173 ++++++++++++++++----------------- > > src/xen_inotify.c | 25 +++- > > src/xen_internal.c | 29 +++-- > > src/xen_unified.c | 176 +++++++++++++++++++++------------- > > src/xen_unified.h | 36 +++++-- > > src/xend_internal.c | 37 ++++++- > > src/xm_internal.c | 256 +++++++++++++++++++++++++++++++++----------------- > > src/xs_internal.c | 130 +++++++++++++++++++------ > > src/xs_internal.h | 7 - > > tests/sexpr2xmltest.c | 19 +++ > > 10 files changed, 575 insertions(+), 313 deletions(-) > > + /* Many puppies died to bring you this code. */ > > This code makes my head spin ... Looks reasonable, but to be honest I ditto > would _only_ trust automated verification that the locks are being > acquired and dropped correctly, and the structure elements are only > being used while locks are acquired. The CIL stuff is doing that? CIL didn't detected all locking bugs in the previous release :-) So far locking bugs seems to have been detected fairly fast, basically the daemon becomes unresponsive and then hooking up a debugger helps finding the stuff out. The problem is that I'm afraid the xen drivers are less tested and have more complex code paths than for the other hypervisors. Still I guess the best is to commit and test as widely as possible is the best way to feel confident about the change, Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list