libxl: ao: cope with fast ao completion with progess events
authorIan Jackson <Ian.Jackson@eu.citrix.com>
Thu, 18 Oct 2012 08:35:02 +0000 (09:35 +0100)
committerIan Jackson <Ian.Jackson@eu.citrix.com>
Thu, 18 Oct 2012 08:35:02 +0000 (09:35 +0100)
commit3f6f3a33d8ad1c81c4a0da7524b25762b6ec6bfd
tree85e7d410cb5ca48ce4bdb9d769cf315cdffe506c
parent5622adc37204b9408d0ee1de57ad16236052f2fd
libxl: ao: cope with fast ao completion with progess events

There are two egcs in an ao initiator: the one in the AO_CREATE
function, and the one in libxl__ao_inprogress.  If synchronous ao
operation generates progress events and completes immediately, the
progress callbacks end up queued in the outer egc.  These callbacks
are currently only called after libxl__ao_inprogress has returned, and
keep the ao alive until they happen.  This is not good because the
principle is that a synchronous ao is not supposed to survive beyond
libxl__ao_inprogress's return.

The fix is to ensure that the callbacks queued in the outer egc are
called early enough that they don't preserve the ao.  This is
straightforward in the AO_INPROGRESS macro because AO_CREATE's egc is
not used inside that macro other than to destroy it.  All we have to
do is destroy it a bit sooner.

This involves unlocking and relocking the ctx since EGC_FREE expects
to be called with the lock released but libxl__ao_inprogress needs it
locked.  This hole in our lock tenure is fine - libxl__ao_inprogress
has such holes already.

It is still possible to use the CTX_LOCK macros for this unlock/lock
because the gc we are using is destroyed only afterwards by
libxl__ao_inprogress.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
tools/libxl/libxl_internal.h