On Mon, May 11, 2009 at 12:47:38PM +0100, Mark McLoughlin wrote:
On Mon, 2009-05-11 at 12:11 +0100, Daniel P. Berrange wrote:
> Back in March I attempted to fix the event loop handling of deleted file
> handles
>
>
http://www.redhat.com/archives/libvir-list/2009-March/msg00246.html
>
> but have merely succeeded in screwing it up in a different fun & exciting
> way. That patch fixed a case where there was a deleted file handle in the
> list at the time virEventRunOnce() starts. Which was nice. Not nice, though
> was that it then breaks the case where a file handle is deleted during the
> course of dispatching events afer poll(). Investigating this also identified
> that when we were marking a file handle as deleted, we were forgetting to
> run virEventInterrupt(), which meant that in some cases the main thread
> would not be woken up until the next event triggers. Not very critical,
> but at the same time, not good because it delays cleanup & release of
> resources.
>
> This series of patches fixes the problems, and more importantly, adds a
> unit test which cover these nasty edge cases.
It's not obvious to me from your description, so for others, one of the
problems these patches fix is where destroying one running guest can
cause another to also be destroyed:
https://bugzilla.redhat.com/499698
NB That's just one symptom. The core problem is that you end up with an
off-by-1 error when dispatching the callbacks. ie, instead of dispatching
the nth callback, we dispatch the nth+1 callbck. There are lots of
different things registering callbacks so effects are pretty unpredictable.
Normally the callbacks for running guests don't align, but if you restart
libvirtd while a set of guests are running, you end up with all the guest
callbacks registered in series, so are quite likely to see this double
destroy.
Daniel
--
|: Red Hat, Engineering, London -o-
http://people.redhat.com/berrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org -o-
http://ovirt.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|