From: Fam Zheng <famz@redhat.com>
To: qemu-devel@nongnu.org
Cc: Kevin Wolf <kwolf@redhat.com>,
qemu-block@nongnu.org, jcody@redhat.com, armbru@redhat.com,
mreitz@redhat.com, Stefan Hajnoczi <stefanha@redhat.com>,
pbonzini@redhat.com
Subject: [Qemu-devel] [PATCH v3 00/12] Fix transactional snapshot with dataplane and NBD export
Date: Fri, 15 May 2015 14:04:16 +0800 [thread overview]
Message-ID: <1431669868-26804-1-git-send-email-famz@redhat.com> (raw)
Changes from v2, which covers virtio-scsi as well:
- Patch 1: Review all bdrv_op_block_all callers.
Document bdrv_op_blocker_add_notifier.
Fix blocking in bdrv_op_blocker_notify.
- Patch 11: Commit message and function comment update.
- Patch 12: New.
Reported by Paolo.
Unlike the iohandler in main loop, iothreads currently process the event
notifier used by virtio-blk ioeventfd in nested aio_poll. This is dangerous
without proper protection, because guest requests could sneak to block layer
where they mustn't.
For example, a QMP transaction may involve multiple bdrv_drain_all() in
handling the list of AioContext it works on. If an aio_poll in one of the
bdrv_drain_all() happens to process a guest VQ kick, and dispatches the
ioeventfd event to virtio-blk, a new guest write is then submitted, and voila,
the transaction semantics is violated.
This series avoids this problem by disabling virtio-blk handlers during
bdrv_drain_all() and transactions.
- Patches 1~3 add the block layer op blocker change notifier code.
- Patches 4,5 secure virtio-blk dataplane.
- Patch 6 secures nbd export.
- Patch 7~10 protect each transaction type from being voilated by new IO
generated in nested aio_poll.
- Patch 11 protects bdrv_drain and bdrv_drain_all.
- Patch 12 does the same protection to virtio-scsi dataplane.
Fam Zheng (12):
block: Add op blocker type "device IO"
block: Add op blocker notifier list
block-backend: Add blk_op_blocker_add_notifier
virtio-blk: Move complete_request to 'ops' structure
virtio-blk: Don't handle output when there is "device IO" op blocker
nbd-server: Clear "can_read" when "device io" blocker is set
blockdev: Block device IO during internal snapshot transaction
blockdev: Block device IO during external snapshot transaction
blockdev: Block device IO during drive-backup transaction
blockdev: Block device IO during blockdev-backup transaction
block: Block "device IO" during bdrv_drain and bdrv_drain_all
virtio-scsi-dataplane: Add "device IO" op blocker listener
block.c | 35 ++++++++++++++++
block/block-backend.c | 6 +++
block/io.c | 22 +++++++++-
blockdev.c | 49 ++++++++++++++++++----
blockjob.c | 1 +
hw/block/dataplane/virtio-blk.c | 37 ++++++++++++++---
hw/block/virtio-blk.c | 69 +++++++++++++++++++++++++++++--
hw/scsi/virtio-scsi-dataplane.c | 91 ++++++++++++++++++++++++++++++++---------
hw/scsi/virtio-scsi.c | 4 ++
include/block/block.h | 9 ++++
include/block/block_int.h | 3 ++
include/hw/virtio/virtio-blk.h | 17 ++++++--
include/hw/virtio/virtio-scsi.h | 3 ++
include/sysemu/block-backend.h | 2 +
migration/block.c | 1 +
nbd.c | 18 ++++++++
16 files changed, 327 insertions(+), 40 deletions(-)
--
2.4.0
next reply other threads:[~2015-05-15 6:04 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-15 6:04 Fam Zheng [this message]
2015-05-15 6:04 ` [Qemu-devel] [PATCH v3 01/12] block: Add op blocker type "device IO" Fam Zheng
2015-05-15 6:22 ` Wen Congyang
2015-05-15 7:06 ` Fam Zheng
2015-05-15 6:04 ` [Qemu-devel] [PATCH v3 02/12] block: Add op blocker notifier list Fam Zheng
2015-05-18 17:22 ` Max Reitz
2015-05-15 6:04 ` [Qemu-devel] [PATCH v3 03/12] block-backend: Add blk_op_blocker_add_notifier Fam Zheng
2015-05-18 17:24 ` Max Reitz
2015-05-15 6:04 ` [Qemu-devel] [PATCH v3 04/12] virtio-blk: Move complete_request to 'ops' structure Fam Zheng
2015-05-18 17:38 ` Max Reitz
2015-05-15 6:04 ` [Qemu-devel] [PATCH v3 05/12] virtio-blk: Don't handle output when there is "device IO" op blocker Fam Zheng
2015-05-18 18:19 ` Max Reitz
2015-05-19 2:58 ` Fam Zheng
2015-05-15 6:04 ` [Qemu-devel] [PATCH v3 06/12] nbd-server: Clear "can_read" when "device io" blocker is set Fam Zheng
2015-05-18 18:35 ` Max Reitz
2015-05-19 2:26 ` Fam Zheng
2015-05-15 6:04 ` [Qemu-devel] [PATCH v3 07/12] blockdev: Block device IO during internal snapshot transaction Fam Zheng
2015-05-15 6:04 ` [Qemu-devel] [PATCH v3 08/12] blockdev: Block device IO during external " Fam Zheng
2015-05-15 6:04 ` [Qemu-devel] [PATCH v3 09/12] blockdev: Block device IO during drive-backup transaction Fam Zheng
2015-05-15 6:04 ` [Qemu-devel] [PATCH v3 10/12] blockdev: Block device IO during blockdev-backup transaction Fam Zheng
2015-05-15 6:04 ` [Qemu-devel] [PATCH v3 11/12] block: Block "device IO" during bdrv_drain and bdrv_drain_all Fam Zheng
2015-05-15 6:04 ` [Qemu-devel] [PATCH v3 12/12] virtio-scsi-dataplane: Add "device IO" op blocker listener Fam Zheng
2015-05-15 6:50 ` Paolo Bonzini
2015-05-15 7:03 ` Fam Zheng
2015-05-15 7:26 ` Paolo Bonzini
2015-05-15 7:57 ` 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=1431669868-26804-1-git-send-email-famz@redhat.com \
--to=famz@redhat.com \
--cc=armbru@redhat.com \
--cc=jcody@redhat.com \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.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).