On 13/03/2015 11:48, Paolo Bonzini wrote:
> > The other possibility is grab a reference for the cpu_register_map_client
> > call,
> > and release it in reschedule_dma. This way the atomics can keep, but we'll
> > need
> > a "finished" flag in DMAAIOCB to avoid double completion.
> Considering this is a slow path, a lock seems preferrable.
And another problem...
You need to be careful about dma_aio_cancel running together with the
continue_after_map_failure, because continue_after_map_failure can be
called by another thread. You could have
continue_after_map_failure dma_aio_cancel
------------------------------------------------------------------
aio_bh_new
qemu_bh_delete
qemu_bh_schedule (use after free)
To fix this, my suggestion is to pass a BH directly to
cpu_register_map_client (possibly to cpu_unregister_map_client as well?
seems to have pros and cons). Then cpu_notify_clients can run entirely
with the lock taken, and not race against cpu_unregister_map_client.
dma_aio_cancel can just do cpu_unregister_map_client followed by
qemu_bh_delete.
Paolo
