qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>,
	qemu-devel@nongnu.org
Cc: famz@redhat.com
Subject: Re: [Qemu-devel] [PATCH 16/19] block: protect modification of dirty bitmaps with a mutex
Date: Tue, 27 Jun 2017 16:26:43 +0200	[thread overview]
Message-ID: <5458c8fb-f73b-6651-b418-87bab8d3d143@redhat.com> (raw)
In-Reply-To: <13257113-2f2b-ccf5-93d1-66b2b963efce@virtuozzo.com>



On 27/06/2017 16:20, Vladimir Sementsov-Ogievskiy wrote:
> I'm likely not right, but for me introducing this mutex looks like dirty
> bitmaps may be accessed from concurrent threads. So for me it looks
> strange that only accessors are protected by the mutex and not the whole
> transactions.

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.

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

  reply	other threads:[~2017-06-27 14:26 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-05 12:38 [Qemu-devel] [PATCH v4 00/19] Block layer thread safety, part 1 Paolo Bonzini
2017-06-05 12:38 ` [Qemu-devel] [PATCH 01/19] block: access copy_on_read with atomic ops Paolo Bonzini
2017-06-05 12:38 ` [Qemu-devel] [PATCH 02/19] block: access quiesce_counter " Paolo Bonzini
2017-06-05 12:38 ` [Qemu-devel] [PATCH 03/19] block: access io_limits_disabled " Paolo Bonzini
2017-06-05 12:38 ` [Qemu-devel] [PATCH 04/19] block: access serialising_in_flight " Paolo Bonzini
2017-06-05 12:38 ` [Qemu-devel] [PATCH 05/19] block: access wakeup " Paolo Bonzini
2017-06-05 12:38 ` [Qemu-devel] [PATCH 06/19] block: access io_plugged " Paolo Bonzini
2017-06-05 12:38 ` [Qemu-devel] [PATCH 07/19] throttle-groups: only start one coroutine from drained_begin Paolo Bonzini
2017-06-05 12:38 ` [Qemu-devel] [PATCH 08/19] throttle-groups: do not use qemu_co_enter_next Paolo Bonzini
2017-06-05 12:38 ` [Qemu-devel] [PATCH 09/19] throttle-groups: protect throttled requests with a CoMutex Paolo Bonzini
2017-06-05 12:38 ` [Qemu-devel] [PATCH 10/19] util: add stats64 module Paolo Bonzini
2017-06-05 12:39 ` [Qemu-devel] [PATCH 11/19] block: use Stat64 for wr_highest_offset Paolo Bonzini
2017-06-05 12:39 ` [Qemu-devel] [PATCH 12/19] block: access write_gen with atomics Paolo Bonzini
2017-06-05 12:39 ` [Qemu-devel] [PATCH 13/19] block: protect tracked_requests and flush_queue with reqs_lock Paolo Bonzini
2017-06-05 12:39 ` [Qemu-devel] [PATCH 14/19] block: introduce dirty_bitmap_mutex Paolo Bonzini
2017-06-05 12:39 ` [Qemu-devel] [PATCH 15/19] migration/block: reset dirty bitmap before reading Paolo Bonzini
2017-06-05 12:39 ` [Qemu-devel] [PATCH 16/19] block: protect modification of dirty bitmaps with a mutex Paolo Bonzini
2017-06-26 16:07   ` Vladimir Sementsov-Ogievskiy
2017-06-26 16:54     ` Paolo Bonzini
2017-06-27  9:07       ` Vladimir Sementsov-Ogievskiy
2017-06-27  9:27         ` Paolo Bonzini
2017-06-27  9:47           ` Vladimir Sementsov-Ogievskiy
2017-06-27 12:52             ` Paolo Bonzini
2017-06-27 13:51               ` Vladimir Sementsov-Ogievskiy
2017-06-27 13:58                 ` Paolo Bonzini
2017-06-27 14:20                   ` Vladimir Sementsov-Ogievskiy
2017-06-27 14:26                     ` Paolo Bonzini [this message]
2017-06-27 14:43                       ` Vladimir Sementsov-Ogievskiy
2017-06-27 14:48                         ` Paolo Bonzini
2017-06-27 15:31                       ` Vladimir Sementsov-Ogievskiy
2017-06-27 15:32                         ` Vladimir Sementsov-Ogievskiy
2017-06-27 15:42                           ` Paolo Bonzini
2017-06-05 12:39 ` [Qemu-devel] [PATCH 17/19] block: introduce block_account_one_io Paolo Bonzini
2017-06-05 12:39 ` [Qemu-devel] [PATCH 18/19] block: split BlockAcctStats creation and setup Paolo Bonzini
2017-06-06 15:43   ` Alberto Garcia
2017-06-05 12:39 ` [Qemu-devel] [PATCH 19/19] block: make accounting thread-safe Paolo Bonzini
2017-06-06 15:45   ` Alberto Garcia
2018-05-24 13:35   ` Alberto Garcia
2018-05-24 13:49     ` Alberto Garcia
2018-05-24 13:49     ` Paolo Bonzini
2017-06-05 13:18 ` [Qemu-devel] [PATCH v4 00/19] Block layer thread safety, part 1 no-reply
2017-06-07  0:04 ` Fam Zheng

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5458c8fb-f73b-6651-b418-87bab8d3d143@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=famz@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=vsementsov@virtuozzo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).