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(a)veillard.com | Rpmfind RPM search engine
http://rpmfind.net/
http://veillard.com/ | virtualization library
http://libvirt.org/