On Donnerstag, 20. August 2020 07:37:28 CEST Gerd Hoffmann wrote:
> Hi,
>
> > > + qemu_bh_cancel(c->shutdown_bh);
> >
> > Looks like a potential race. Quote from the API doc of qemu_bh_cancel():
> > "While cancellation itself is also wait-free and thread-safe, it can of
> > course race with the loop that executes bottom halves unless you are
> > holding the iothread mutex. This makes it mostly useless if you are not
> > holding the mutex."
>
> Should not be a problem, all auto backend code should only be called
> while qemu holds the iothread mutex. With the exception of the shutdown
> handler which jack might call from signal context (which is why we need
> the BH in the first place).
Hmmm, as Geoffrey already added a lock today, I noticed that QEMU's main IO
thread mutex is not initialized as 'recursive' lock type. Does that make
sense? I.e. shouldn't there be a
qemu_rec_mutex_init(&qemu_global_mutex);
in softmmu/cpus.c for safety reasons to prevent nested locks from same thread
causing misbehaviour?
CCing Paolo to clarify.
Best regards,
Christian Schoenebeck
