|
 |
9bac43 |
From 47357547c1040e029aec3e1d9e850d6249bc2bbb Mon Sep 17 00:00:00 2001
|
|
|
9bac43 |
From: Kevin Wolf <kwolf@redhat.com>
|
|
|
9bac43 |
Date: Mon, 15 Jan 2018 11:23:36 +0100
|
|
|
9bac43 |
Subject: [PATCH 11/12] block: Don't request I/O permission with BDRV_O_NO_IO
|
|
|
9bac43 |
|
|
|
9bac43 |
RH-Author: Kevin Wolf <kwolf@redhat.com>
|
|
|
9bac43 |
Message-id: <20180115112337.20885-3-kwolf@redhat.com>
|
|
|
9bac43 |
Patchwork-id: 78575
|
|
|
9bac43 |
O-Subject: [RHV-7.5 qemu-kvm-rhev PATCH 2/3] block: Don't request I/O permission with BDRV_O_NO_IO
|
|
|
9bac43 |
Bugzilla: 1515604
|
|
|
9bac43 |
RH-Acked-by: Stefan Hajnoczi <stefanha@redhat.com>
|
|
|
9bac43 |
RH-Acked-by: Jeffrey Cody <jcody@redhat.com>
|
|
|
9bac43 |
RH-Acked-by: John Snow <jsnow@redhat.com>
|
|
|
9bac43 |
|
|
|
9bac43 |
'qemu-img info' makes sense even when BLK_PERM_CONSISTENT_READ cannot be
|
|
|
9bac43 |
granted because of a block job in a running qemu process. It already
|
|
|
9bac43 |
sets BDRV_O_NO_IO to indicate that it doesn't access the guest visible
|
|
|
9bac43 |
data at all.
|
|
|
9bac43 |
|
|
|
9bac43 |
Check the BDRV_O_NO_IO flags in blk_new_open(), so that I/O related
|
|
|
9bac43 |
permissions are not unnecessarily requested and 'qemu-img info' can work
|
|
|
9bac43 |
even if BLK_PERM_CONSISTENT_READ cannot be granted.
|
|
|
9bac43 |
|
|
|
9bac43 |
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
|
|
|
9bac43 |
Reviewed-by: Fam Zheng <famz@redhat.com>
|
|
|
9bac43 |
Reviewed-by: Alberto Garcia <berto@igalia.com>
|
|
|
9bac43 |
(cherry picked from commit 1f4ad7d3b8f7162ec0471506d86f57a5d77b8f76)
|
|
|
9bac43 |
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
|
|
|
9bac43 |
Signed-off-by: Miroslav Rezanina <mrezanin@redhat.com>
|
|
|
9bac43 |
---
|
|
|
9bac43 |
block/block-backend.c | 10 ++++++----
|
|
|
9bac43 |
1 file changed, 6 insertions(+), 4 deletions(-)
|
|
|
9bac43 |
|
|
|
9bac43 |
diff --git a/block/block-backend.c b/block/block-backend.c
|
|
|
9bac43 |
index 083e65f..dce8b96 100644
|
|
|
9bac43 |
--- a/block/block-backend.c
|
|
|
9bac43 |
+++ b/block/block-backend.c
|
|
|
9bac43 |
@@ -299,7 +299,7 @@ BlockBackend *blk_new_open(const char *filename, const char *reference,
|
|
|
9bac43 |
{
|
|
|
9bac43 |
BlockBackend *blk;
|
|
|
9bac43 |
BlockDriverState *bs;
|
|
|
9bac43 |
- uint64_t perm;
|
|
|
9bac43 |
+ uint64_t perm = 0;
|
|
|
9bac43 |
|
|
|
9bac43 |
/* blk_new_open() is mainly used in .bdrv_create implementations and the
|
|
|
9bac43 |
* tools where sharing isn't a concern because the BDS stays private, so we
|
|
|
9bac43 |
@@ -309,9 +309,11 @@ BlockBackend *blk_new_open(const char *filename, const char *reference,
|
|
|
9bac43 |
* caller of blk_new_open() doesn't make use of the permissions, but they
|
|
|
9bac43 |
* shouldn't hurt either. We can still share everything here because the
|
|
|
9bac43 |
* guest devices will add their own blockers if they can't share. */
|
|
|
9bac43 |
- perm = BLK_PERM_CONSISTENT_READ;
|
|
|
9bac43 |
- if (flags & BDRV_O_RDWR) {
|
|
|
9bac43 |
- perm |= BLK_PERM_WRITE;
|
|
|
9bac43 |
+ if ((flags & BDRV_O_NO_IO) == 0) {
|
|
|
9bac43 |
+ perm |= BLK_PERM_CONSISTENT_READ;
|
|
|
9bac43 |
+ if (flags & BDRV_O_RDWR) {
|
|
|
9bac43 |
+ perm |= BLK_PERM_WRITE;
|
|
|
9bac43 |
+ }
|
|
|
9bac43 |
}
|
|
|
9bac43 |
if (flags & BDRV_O_RESIZE) {
|
|
|
9bac43 |
perm |= BLK_PERM_RESIZE;
|
|
|
9bac43 |
--
|
|
|
9bac43 |
1.8.3.1
|
|
|
9bac43 |
|