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

Re: [libvirt] Potential race condition problem



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


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