yeahuh / rpms / qemu-kvm

Forked from rpms/qemu-kvm 2 years ago
Clone

Blame SOURCES/kvm-iotests-Test-file-posix-locking-and-reopen.patch

b38b0f
From 45fd7df81a04ef0cdc2e67fee6f8047ec2a3c7cd Mon Sep 17 00:00:00 2001
b38b0f
From: Max Reitz <mreitz@redhat.com>
b38b0f
Date: Wed, 3 Apr 2019 17:13:14 +0100
b38b0f
Subject: [PATCH 07/11] iotests: Test file-posix locking and reopen
b38b0f
b38b0f
RH-Author: Max Reitz <mreitz@redhat.com>
b38b0f
Message-id: <20190403171315.20841-8-mreitz@redhat.com>
b38b0f
Patchwork-id: 85405
b38b0f
O-Subject: [RHEL-8.1 qemu-kvm PATCH 7/8] iotests: Test file-posix locking and reopen
b38b0f
Bugzilla: 1694148
b38b0f
RH-Acked-by: John Snow <jsnow@redhat.com>
b38b0f
RH-Acked-by: Stefan Hajnoczi <stefanha@redhat.com>
b38b0f
RH-Acked-by: Stefano Garzarella <sgarzare@redhat.com>
b38b0f
b38b0f
Signed-off-by: Max Reitz <mreitz@redhat.com>
b38b0f
Reviewed-by: Alberto Garcia <berto@igalia.com>
b38b0f
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
b38b0f
(cherry picked from commit 6d0a4a0fb5c8f10c8eb68b52cfda0082b00ae963)
b38b0f
Signed-off-by: Max Reitz <mreitz@redhat.com>
b38b0f
Signed-off-by: Danilo C. L. de Paula <ddepaula@redhat.com>
b38b0f
---
b38b0f
 tests/qemu-iotests/182     | 71 ++++++++++++++++++++++++++++++++++++++++++++++
b38b0f
 tests/qemu-iotests/182.out |  9 ++++++
b38b0f
 2 files changed, 80 insertions(+)
b38b0f
b38b0f
diff --git a/tests/qemu-iotests/182 b/tests/qemu-iotests/182
b38b0f
index 4b31592..3b7689c 100755
b38b0f
--- a/tests/qemu-iotests/182
b38b0f
+++ b/tests/qemu-iotests/182
b38b0f
@@ -31,6 +31,7 @@ status=1	# failure is the default!
b38b0f
 _cleanup()
b38b0f
 {
b38b0f
     _cleanup_test_img
b38b0f
+    rm -f "$TEST_IMG.overlay"
b38b0f
 }
b38b0f
 trap "_cleanup; exit \$status" 0 1 2 3 15
b38b0f
 
b38b0f
@@ -71,6 +72,76 @@ echo 'quit' | $QEMU -nographic -monitor stdio \
b38b0f
 
b38b0f
 _cleanup_qemu
b38b0f
 
b38b0f
+echo
b38b0f
+echo '=== Testing reopen ==='
b38b0f
+echo
b38b0f
+
b38b0f
+# This tests that reopening does not unshare any permissions it should
b38b0f
+# not unshare
b38b0f
+# (There was a bug where reopening shared exactly the opposite of the
b38b0f
+# permissions it was supposed to share)
b38b0f
+
b38b0f
+_launch_qemu
b38b0f
+
b38b0f
+_send_qemu_cmd $QEMU_HANDLE \
b38b0f
+    "{'execute': 'qmp_capabilities'}" \
b38b0f
+    'return'
b38b0f
+
b38b0f
+# Open the image without any format layer (we are not going to access
b38b0f
+# it, so that is fine)
b38b0f
+# This should keep all permissions shared.
b38b0f
+success_or_failure=y _send_qemu_cmd $QEMU_HANDLE \
b38b0f
+    "{'execute': 'blockdev-add',
b38b0f
+      'arguments': {
b38b0f
+          'node-name': 'node0',
b38b0f
+          'driver': 'file',
b38b0f
+          'filename': '$TEST_IMG',
b38b0f
+          'locking': 'on'
b38b0f
+          } }" \
b38b0f
+    'return' \
b38b0f
+    'error'
b38b0f
+
b38b0f
+# This snapshot will perform a reopen to drop R/W to RO.
b38b0f
+# It should still keep all permissions shared.
b38b0f
+success_or_failure=y _send_qemu_cmd $QEMU_HANDLE \
b38b0f
+    "{'execute': 'blockdev-snapshot-sync',
b38b0f
+      'arguments': {
b38b0f
+          'node-name': 'node0',
b38b0f
+          'snapshot-file': '$TEST_IMG.overlay',
b38b0f
+          'snapshot-node-name': 'node1'
b38b0f
+      } }" \
b38b0f
+    'return' \
b38b0f
+    'error'
b38b0f
+
b38b0f
+# Now open the same file again
b38b0f
+# This does not require any permissions (and does not unshare any), so
b38b0f
+# this will not conflict with node0.
b38b0f
+success_or_failure=y _send_qemu_cmd $QEMU_HANDLE \
b38b0f
+    "{'execute': 'blockdev-add',
b38b0f
+      'arguments': {
b38b0f
+          'node-name': 'node1',
b38b0f
+          'driver': 'file',
b38b0f
+          'filename': '$TEST_IMG',
b38b0f
+          'locking': 'on'
b38b0f
+          } }" \
b38b0f
+    'return' \
b38b0f
+    'error'
b38b0f
+
b38b0f
+# Now we attach the image to a virtio-blk device.  This device does
b38b0f
+# require some permissions (at least WRITE and READ_CONSISTENT), so if
b38b0f
+# reopening node0 unshared any (which it should not have), this will
b38b0f
+# fail (but it should not).
b38b0f
+success_or_failure=y _send_qemu_cmd $QEMU_HANDLE \
b38b0f
+    "{'execute': 'device_add',
b38b0f
+      'arguments': {
b38b0f
+          'driver': 'virtio-blk',
b38b0f
+          'drive': 'node1'
b38b0f
+      } }" \
b38b0f
+    'return' \
b38b0f
+    'error'
b38b0f
+
b38b0f
+_cleanup_qemu
b38b0f
+
b38b0f
 # success, all done
b38b0f
 echo "*** done"
b38b0f
 rm -f $seq.full
b38b0f
diff --git a/tests/qemu-iotests/182.out b/tests/qemu-iotests/182.out
b38b0f
index f1463c8..af501ca 100644
b38b0f
--- a/tests/qemu-iotests/182.out
b38b0f
+++ b/tests/qemu-iotests/182.out
b38b0f
@@ -5,4 +5,13 @@ Starting QEMU
b38b0f
 Starting a second QEMU using the same image should fail
b38b0f
 QEMU_PROG: -drive file=TEST_DIR/t.qcow2,if=none,id=drive0,file.locking=on: Failed to get "write" lock
b38b0f
 Is another process using the image [TEST_DIR/t.qcow2]?
b38b0f
+
b38b0f
+=== Testing reopen ===
b38b0f
+
b38b0f
+{"return": {}}
b38b0f
+{"return": {}}
b38b0f
+Formatting 'TEST_DIR/t.qcow2.overlay', fmt=qcow2 size=197120 backing_file=TEST_DIR/t.qcow2 backing_fmt=file cluster_size=65536 lazy_refcounts=off refcount_bits=16
b38b0f
+{"return": {}}
b38b0f
+{"return": {}}
b38b0f
+{"return": {}}
b38b0f
 *** done
b38b0f
-- 
b38b0f
1.8.3.1
b38b0f