On 01/10/2018 18:03, Kevin Wolf wrote: >> Given the backtrace, I think bdrv_close should be taking the AioContext >> lock instead of blockdev_close_all_bdrv_states. > Conversely, that would mean that calling bdrv_unref() with the > AioContext lock held is a bug (because close callbacks can involve > AIO_WAIT_WHILE()). I'm not sure if that's very practical.
What if bdrv_unref_child dropped the lock? Perhaps it's simpler to just kill the lock though, if bdrv_set_aio_context can be figured out. Paolo > Of course, there will probably be a lot of callers to fix either way > after we define whether to hold the lock for bdrv_unref() or not. Either > you need to add locking to the places where it's missing or you need to > drop the locks in all other places. > > I was leaning towards requiring the lock for bdrv_unref() (and > therefore blk_unref()).
