[libvirt] Potential race condition problem

Daniel P. Berrange berrange at redhat.com
Mon Oct 1 08:15:25 UTC 2012


On Sat, Sep 29, 2012 at 07:07:15AM +0000, Benjamin Wang (gendwang) wrote:
> Hi,
>    Currently virInitialize() method defined in libvirt.c has the following code:
> int
> virInitialize(void)
> {
>     if (initialized)
>         return 0;
> 
>     initialized = 1;
> 
>     if (virThreadInitialize() < 0 ||
>         virErrorInitialize() < 0 ||
>         virRandomInitialize(time(NULL) ^ getpid()) ||
>         virNodeSuspendInit() < 0)
>         return -1;
> 
> ......
> }
> 
> When two threads access virInitialize method, there is no lock for the
 "initialized" parameter. If the first thread enters this method and set
> "initialized" to 1, the second thread could see that "initialized" is
> 1(Because initialized is not volatiled, I say could). In some situation,
> before the first thread finishes all the initialization,
> the second thread could use some resources which should be initialized
> in Initialize method.
> If you have any comments, please let me know. Thanks!

The API docs tell you to call this method upfront to avoid race
conditions with multiple threads. So if you have multiple threads
calling virInitialize in parallel, that is an application bug.


That said, we could switch virInitilize to use our new one-time
init support to remove this restriction in future libvirt.

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




More information about the libvir-list mailing list