|
From: | Vladimir Sementsov-Ogievskiy |
Subject: | Re: [Qemu-devel] [PATCH 16/19] block: protect modification of dirty bitmaps with a mutex |
Date: | Tue, 27 Jun 2017 18:32:50 +0300 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 |
27.06.2017 18:31, Vladimir Sementsov-Ogievskiy wrote:
27.06.2017 17:26, Paolo Bonzini wrote:On 27/06/2017 16:20, Vladimir Sementsov-Ogievskiy wrote:I'm likely not right, but for me introducing this mutex looks like dirtybitmaps may be accessed from concurrent threads. So for me it looksstrange that only accessors are protected by the mutex and not the wholetransactions.There must be something else protecting the whole transaction.One example I've wrote above, other examples from code: are qmp_block_dirty_bitmap** functions: bdrv_create_dirty_bitmap() { bdrv_find_dirty_bitmap() .... bdrv_dirty_bitmaps_lock(bs); QLIST_INSERT_HEAD(&bs->dirty_bitmaps, bitmap, list); bdrv_dirty_bitmaps_unlock(bs); } - we protect inserting into list from other threads, but what prevent creating bitmap with the same name from other thread after bdrv_find_dirty_bitmap() and before bdrv_dirty_bitmaps_lock() ?It's like a read-write lock.Ok, finally I understand (not all, but the main idea=), sorry for annoying.
Is there any example of accessing dirty bitmaps for read not under BQL but only under dirty bitmap lock?
The write side is invoked under the 'big QEMU lock' so there cannot be two concurrent writes. A bitmap can be written to after bdrv_find_dirty_bitmap returns, but only if _you_ tell another thread about the bitmap you've just created. If that doesn't happen, the bitmap cannot change. And it can also disappear because _your_ thread is the one with the big QEMU lock. Paolo
-- Best regards, Vladimir
[Prev in Thread] | Current Thread | [Next in Thread] |