[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] [PATCH] block: avoid recursive AioContext acquire in bd
Re: [Qemu-block] [PATCH] block: avoid recursive AioContext acquire in bdrv_inactivate_all()
Thu, 7 Dec 2017 14:46:32 +0000
On Wed, Dec 06, 2017 at 07:40:28PM +0100, Kevin Wolf wrote:
> Am 06.12.2017 um 18:54 hat Stefan Hajnoczi geschrieben:
> > From: Paolo Bonzini <address@hidden>
> > BDRV_POLL_WHILE() does not support recursive AioContext locking. It
> > only releases the AioContext lock once regardless of how many times the
> > caller has acquired it. This results in a hang since the IOThread does
> > not make progress while the AioContext is still locked.
> > The following steps trigger the hang:
> > $ qemu-system-x86_64 -M accel=kvm -m 1G -cpu host \
> > -object iothread,id=iothread0 \
> > -device virtio-scsi-pci,iothread=iothread0 \
> > -drive if=none,id=drive0,file=test.img,format=raw \
> > -device scsi-hd,drive=drive0 \
> > -drive if=none,id=drive1,file=test.img,format=raw \
> > -device scsi-hd,drive=drive1
> > $ qemu-system-x86_64 ...same options... \
> > -incoming tcp::1234
> > (qemu) migrate tcp:127.0.0.1:1234
> > ...hang...
> Please turn this into a test case.
> We should probably also update docs/devel/multiple-iothreads.txt.
> Currently it says:
> aio_context_acquire()/aio_context_release() calls may be nested.
> This means you can call them if you're not sure whether #2 applies.
> While technically that's still correct as far as the lock is concerned,
> the limitations of BDRV_POLL_WHILE() mean that in practice this is not a
> viable option any more at least in the context of the block layer.
Good point, will fix both things in v2.
Description: PGP signature