[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [PATCH] block: Acquire the AioContext in guess_disk_lch

From: Kevin Wolf
Subject: Re: [Qemu-block] [PATCH] block: Acquire the AioContext in guess_disk_lchs()
Date: Wed, 9 Jan 2019 16:07:33 +0100
User-agent: Mutt/1.10.1 (2018-07-13)

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 <address@hidden>

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

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. :-))


reply via email to

[Prev in Thread] Current Thread [Next in Thread]