Re: [PATCH 08/10] Add test case for loading driver modules

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, May 21, 2012 at 09:56:19PM -0600, Eric Blake wrote:
> On 05/21/2012 01:59 PM, Daniel P. Berrange wrote:
> > From: "Daniel P. Berrange" <berrange@xxxxxxxxxx>
> > 
> > To ensure all symbols used by loadable driver modules are
> > exported in libvirt.so, add a test suite that simply loads
> > each driver in turn
> > 
> > * tests/Makefile.am, tests/virdrivermoduletest.c: Add
> >   a test case for loading drivers
> > 
> > Signed-off-by: Daniel P. Berrange <berrange@xxxxxxxxxx>
> > ---
> >  tests/Makefile.am           |   11 +++++
> >  tests/virdrivermoduletest.c |  104 +++++++++++++++++++++++++++++++++++++++++++
> >  2 files changed, 115 insertions(+), 0 deletions(-)
> >  create mode 100644 tests/virdrivermoduletest.c
> 
> ACK.
> 
> 
> > +static int testDriverModule(const void *args)
> > +{
> > +    const struct testDriverData *data = args;
> > +
> > +    if (data->dep1 &&
> > +        !virDriverLoadModule(data->dep1))
> > +        return -1;
> > +
> > +    if (!virDriverLoadModule(data->name))
> > +        return -1;
> > +
> > +    return 0;
> > +}
> 
> Any reason why we don't have a virDriverUnloadModule?

Unloading dynamic libraries can trigger a world of hurt in threaded
applications which use thread locals. eg this previous fix:


  commit 8e44e5593eb9b89fbc0b54fde15f130707a0d81e
  Author: Daniel P. Berrange <berrange@xxxxxxxxxx>
  Date:   Thu Sep 1 17:57:06 2011 +0100

    Prevent crash from dlclose() of libvirt.so
    
    When libvirt calls virInitialize it creates a thread local
    for the virErrorPtr storage, and registers a callback to
    cleanup memory when a thread exits. When libvirt is dlclose()d
    or otherwise made non-resident, the callback function is
    removed from memory, but the thread local may still exist
    and if a thread later exists, it will invoke the callback
    and SEGV. There may also be other thread locals with callbacks
    pointing to libvirt code, so it is in general never safe to
    unload libvirt.so from memory once initialized.
    
    To allow dlclose() to succeed, but keep libvirt.so resident
    in memory, link with '-z nodelete'. This issue was first
    found with the libvirt CIM provider, but can potentially
    hit many of the dynamic language bindings which all ultimately
    involve dlopen() in some way, either on libvirt.so itself,
    or on the glue code for the binding which in turns links
    to libvirt

while this applied to libvirt.so used by client applcations,
IMHO, the same problem exists wrt to libvirtd & loadable
driver modules.

Since I see no compelling reason to unload modules, it is safer
to just not support it.

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]