Am 09.01.2019 um 15:28 hat Alberto Garcia geschrieben:
> This fixes the following crash:
>
> { "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": "device_add",
> "arguments": {"id": "virtio0", "driver": "virtio-blk-pci",
> "drive": "hd0"}}
> qemu: qemu_mutex_unlock_impl: Operation not permitted
> Aborted
>
> Signed-off-by: Alberto Garcia <be...@igalia.com>
This looks like the same thing that I talked about with Markus
yesterday. He asked me where to put the acquire/release pair. My answer
was that there is more than one way to do it, but I suspect that the
realize functions of the devices may call the block layer more than once
and putting the acquire/release there might be nicer. We would then
document blkconf_geometry() to assume that the AioContext is already
locked.
There are many calls for node management stuff where we never defined
the locking rules, but where we might reasonably assume that they only
affect things that are only ever accessed from the main thread. But
there are also things like blk_ioctl() in scsi_block_realize(), which
should most certainly run with the lock held.
What do you think?
(I also wondered whether virtio-blk is affected as well or whether it
moves the BlockBackend to the iothread AioContext only later. Your
reproducer answers this question. :-))
Kevin
