Re: [Qemu-block] Crash when deleting an iothread that is being used

[Stefan Hajnoczi]

On Tue, Jan 15, 2019 at 03:29:42PM +0200, Alberto Garcia wrote:
> Here's how to reproduce the crash:
> 
> { "execute": "qmp_capabilities" }
> { "execute": "blockdev-add", "arguments": {"driver": "null-co", "node-name": 
> "hd0"}}
> { "execute": "object-add", "arguments": {"qom-type": "iothread", "id": 
> "iothread0"}}
> { "execute": "x-blockdev-set-iothread", "arguments": {"node-name": "hd0", 
> "iothread": "iothread0"}}
> { "execute": "object-del", "arguments": {"id": "iothread0"}}
> { "execute": "blockdev-del", "arguments": {"node-name": "hd0"}}
> 
> The problem is that bs->aio_context is the one that belonged to the
> IOThread and was destroyed by the object-del call. One would need to
> do x-blockdev-set-iothread(hd0, null) before deleting the thread.
> 
> The IOThread class does not have a can_be_deleted() method to prevent
> threads from being deleted. One possible implementation would require
> a reference count but that doesn't seem immediately trivial because
> users don't use the IOThread itself but its AioContext, and not all
> bdrv_set_aio_context() are related to IOThreads.
> 
> A quicker fix is of course to prevent the threads from being deleted
> at all :-)

What is the real-world scenario for crashes like this?

object-del on an IOThread that is currently in use by
virtio-blk/virtio-scsi?

I'm asking because x-blockdev-set-iothread is a low-level testing
command and it can create IOThread configurations that real-world users
never reach.  It's only worth worrying about if users are affected.

Stefan

signature.asc
Description: PGP signature