From nobody Mon Feb 9 08:58:05 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 209.51.188.17 as permitted sender) client-ip=209.51.188.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; spf=pass (zoho.com: domain of gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org; dmarc=fail(p=none dis=none) header.from=redhat.com Return-Path: Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mx.zohomail.com with SMTPS id 1554260889897985.4043340154157; Tue, 2 Apr 2019 20:08:09 -0700 (PDT) Received: from localhost ([127.0.0.1]:40570 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hBWFh-0001sU-Kq for importer@patchew.org; Tue, 02 Apr 2019 23:07:49 -0400 Received: from eggs.gnu.org ([209.51.188.92]:41738) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hBWDc-0000KV-Bj for qemu-devel@nongnu.org; Tue, 02 Apr 2019 23:05:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hBWDb-0005BT-6e for qemu-devel@nongnu.org; Tue, 02 Apr 2019 23:05:40 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38812) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hBWDY-0004vc-6I; Tue, 02 Apr 2019 23:05:36 -0400 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7E58883F40; Wed, 3 Apr 2019 03:05:35 +0000 (UTC) Received: from blue.redhat.com (ovpn-116-168.phx2.redhat.com [10.3.116.168]) by smtp.corp.redhat.com (Postfix) with ESMTP id D1E1B19C68; Wed, 3 Apr 2019 03:05:34 +0000 (UTC) From: Eric Blake To: qemu-devel@nongnu.org Date: Tue, 2 Apr 2019 22:05:23 -0500 Message-Id: <20190403030526.12258-5-eblake@redhat.com> In-Reply-To: <20190403030526.12258-1-eblake@redhat.com> References: <20190403030526.12258-1-eblake@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Wed, 03 Apr 2019 03:05:35 +0000 (UTC) Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.132.183.28 Subject: [Qemu-devel] [PATCH 4/7] iotests: Update 241 to expose backing layer fragmentation X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Kevin Wolf , vsementsov@virtuozzo.com, jsnow@redhat.com, qemu-block@nongnu.org, Max Reitz Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" Content-Type: text/plain; charset="utf-8" Previous commits have mentioned that our NBD server still sends unaligned fragments when an active layer with large advertised minimum block size is backed by another layer with a smaller block size. Expand the test to actually cover this scenario, by using qcow2 encryption (which forces 512-byte alignment) with an unaligned raw backing file. The test passes, but only because the client side works around the server's non-compliance; if you repeat the test manually with tracing turned on, you will see the server sending a status for 1000 bytes data then 1048 bytes hole, which is not aligned. But reverting commit 737d3f5244 shows that it is indeed the client working around the bug in the server. Signed-off-by: Eric Blake Reviewed-by: Vladimir Sementsov-Ogievskiy Tested-by: Vladimir Sementsov-Ogievskiy --- tests/qemu-iotests/241 | 20 +++++++++++++++++++- tests/qemu-iotests/241.out | 9 +++++++++ 2 files changed, 28 insertions(+), 1 deletion(-) diff --git a/tests/qemu-iotests/241 b/tests/qemu-iotests/241 index 4b196857387..c1fa6980dc8 100755 --- a/tests/qemu-iotests/241 +++ b/tests/qemu-iotests/241 @@ -28,6 +28,7 @@ nbd_unix_socket=3D$TEST_DIR/test_qemu_nbd_socket _cleanup() { _cleanup_test_img + rm -f "$TEST_IMAGE_FILE.qcow2" nbd_server_stop } trap "_cleanup; exit \$status" 0 1 2 3 15 @@ -37,7 +38,7 @@ trap "_cleanup; exit \$status" 0 1 2 3 15 . ./common.filter . ./common.nbd -_supported_fmt raw +_supported_fmt raw # although the test also requires use of qcow2 _supported_proto nbd _supported_os Linux _require_command QEMU_NBD @@ -88,6 +89,23 @@ $QEMU_IMG map --output=3Djson "$TEST_IMG" | _filter_qemu= _img_map $QEMU_IO -c map "$TEST_IMG" nbd_server_stop +echo +echo "=3D=3D=3D Encrypted qcow2 file backed by unaligned raw image =3D=3D= =3D" +echo + +# Enabling encryption in qcow2 forces 512-alignment +SECRET=3Dsecret,id=3Dsec0,data=3D12345 +$QEMU_IMG create -f qcow2 -b "$TEST_IMG_FILE" -F raw --object "$SECRET" \ + -o encrypt.format=3Dluks,encrypt.key-secret=3Dsec0,encrypt.iter-time=3D1= 0 \ + "$TEST_IMG_FILE.qcow2" 2k | _filter_img_create +nbd_server_start_unix_socket --object "$SECRET" --image-opts \ + driver=3Dqcow2,file.filename=3D"$TEST_IMG_FILE.qcow2",encrypt.key-secret= =3Dsec0 + +$QEMU_NBD_PROG --list -k $nbd_unix_socket | grep '\(size\|min\)' +$QEMU_IMG map --output=3Djson "$TEST_IMG" | _filter_qemu_img_map +$QEMU_IO -c map "$TEST_IMG" +nbd_server_stop + # Not tested yet: we also want to ensure that qemu as NBD client does # not access beyond the end of a server's advertised unaligned size: # nbdkit -U - memory size=3D513 --run 'qemu-io -f raw -c "r 512 512" $nbd' diff --git a/tests/qemu-iotests/241.out b/tests/qemu-iotests/241.out index f481074a02e..ef7de1205d2 100644 --- a/tests/qemu-iotests/241.out +++ b/tests/qemu-iotests/241.out @@ -25,4 +25,13 @@ WARNING: Image format was not specified for '/home/eblak= e/qemu/tests/qemu-iotest [{ "start": 0, "length": 1000, "depth": 0, "zero": false, "data": true, "o= ffset": OFFSET}, { "start": 1000, "length": 24, "depth": 0, "zero": true, "data": true, "of= fset": OFFSET}] 1 KiB (0x400) bytes allocated at offset 0 bytes (0x0) + +=3D=3D=3D Encrypted qcow2 file backed by unaligned raw image =3D=3D=3D + +Formatting 'TEST_DIR/t.IMGFMT.qcow2', fmt=3Dqcow2 size=3D2048 backing_file= =3DTEST_DIR/t.IMGFMT backing_fmt=3DIMGFMT encrypt.format=3Dluks encrypt.key= -secret=3Dsec0 encrypt.iter-time=3D10 + size: 2048 + min block: 512 +[{ "start": 0, "length": 1024, "depth": 0, "zero": false, "data": true, "o= ffset": OFFSET}, +{ "start": 1024, "length": 1024, "depth": 0, "zero": true, "data": false, = "offset": OFFSET}] +2 KiB (0x800) bytes allocated at offset 0 bytes (0x0) *** done --=20 2.20.1