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
