From: Kevin Wolf <kwolf@redhat.com>
To: qemu-block@nongnu.org
Cc: kwolf@redhat.com, mreitz@redhat.com, famz@redhat.com,
eblake@redhat.com, qemu-devel@nongnu.org
Subject: [Qemu-devel] [PATCH for-2.11 2/2] block: Don't request I/O permission with BDRV_O_NO_IO
Date: Mon, 20 Nov 2017 15:11:41 +0100 [thread overview]
Message-ID: <20171120141141.24626-3-kwolf@redhat.com> (raw)
In-Reply-To: <20171120141141.24626-1-kwolf@redhat.com>
'qemu-img info' makes sense even when BLK_PERM_CONSISTENT_READ cannot be
granted because of a block job in a running qemu process. It already
sets BDRV_O_NO_IO to indicate that it doesn't access the guest visible
data at all.
Check the BDRV_O_NO_IO flags in blk_new_open(), so that I/O related
permissions are not unnecessarily requested and 'qemu-img info' can work
even if BLK_PERM_CONSISTENT_READ cannot be granted.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
---
block/block-backend.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/block/block-backend.c b/block/block-backend.c
index 5836cb3087..baef8e7abc 100644
--- a/block/block-backend.c
+++ b/block/block-backend.c
@@ -299,7 +299,7 @@ BlockBackend *blk_new_open(const char *filename, const char *reference,
{
BlockBackend *blk;
BlockDriverState *bs;
- uint64_t perm;
+ uint64_t perm = 0;
/* blk_new_open() is mainly used in .bdrv_create implementations and the
* tools where sharing isn't a concern because the BDS stays private, so we
@@ -309,9 +309,11 @@ BlockBackend *blk_new_open(const char *filename, const char *reference,
* caller of blk_new_open() doesn't make use of the permissions, but they
* shouldn't hurt either. We can still share everything here because the
* guest devices will add their own blockers if they can't share. */
- perm = BLK_PERM_CONSISTENT_READ;
- if (flags & BDRV_O_RDWR) {
- perm |= BLK_PERM_WRITE;
+ if ((flags & BDRV_O_NO_IO) == 0) {
+ perm |= BLK_PERM_CONSISTENT_READ;
+ if (flags & BDRV_O_RDWR) {
+ perm |= BLK_PERM_WRITE;
+ }
}
if (flags & BDRV_O_RESIZE) {
perm |= BLK_PERM_RESIZE;
--
2.13.6
next prev parent reply other threads:[~2017-11-20 14:12 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-20 14:11 [Qemu-devel] [PATCH for-2.11 0/2] Fix 'qemu-img info' on mirror target Kevin Wolf
2017-11-20 14:11 ` [Qemu-devel] [PATCH for-2.11 1/2] block: Don't use BLK_PERM_CONSISTENT_READ for format probing Kevin Wolf
2017-11-20 14:11 ` Kevin Wolf [this message]
2017-11-20 14:41 ` [Qemu-devel] [Qemu-block] [PATCH for-2.11 2/2] block: Don't request I/O permission with BDRV_O_NO_IO Alberto Garcia
2017-11-20 14:22 ` [Qemu-devel] [PATCH for-2.11 0/2] Fix 'qemu-img info' on mirror target 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=20171120141141.24626-3-kwolf@redhat.com \
--to=kwolf@redhat.com \
--cc=eblake@redhat.com \
--cc=famz@redhat.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.