[Xen-devel] [PATCH for-4.5 0/6] libxl: events: Tear down fd interests when idle

[Ian Jackson <ian.jackson@xxxxxxxxxxxxx>]

If libxl_event_register_callbacks is called with nonzero hooks while
any part of libxl has any fd interests registered internally, then:

 * There is no way for libxl to notify the application that it wants
   to be told about these fds, because the spec in the doc comment
   says that the new hooks are not called for existing interests.

 * When libxl becomes no longer interested, it will try to find the
   nexus for the deregistration hook.  But such a nexus is only set up
   with nonzero hooks, so libxl will dereference NULL.

 * Specifically, since 66bff9fd492f, libxl would unconditionally
   become interested in its event channel fd during setup.  So if the
   application sets nontrivial hooks it will always crash in
   libxl_ctx_free.  (This case reported as a bug by Ian Campbell.)

To fix this, it would be nice to simply forbid `late' registration of
event hooks.  But this would be an incompatible API changel.  And
indeed libvirt already registers event hooks after using the ctx to
create a domain (!)

So instead we add the minimum workable restriction: hooks can (only)
be registered when libxl is idle.

To do this we need to:
 * Defer registration of fds until they are needed.
 * Deregister fds again as they become idle.
There is no need to do anything about timeouts because an idle libxl
already never has any timeouts.

In this series I add defensive assertions.  This is a good idea
because violations of the rules typically produce crashes anyway, but
distant from the cause.


This series should be included in Xen 4.5:

The evtchn fd issue is new in 4.5 - that is, we have a regression
since 4.4.  It causes libvirt to segfault.

But even in 4.4 there are potential bugs, with symptoms such as the
libxl watch fd not being properly registered, so that operations are
unreasonably delayed, or crashes on ctx teardown.  So after these
patches make it into 4.5 master the relevant subset should probably be
backported.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel