From nobody Sun Oct 5 19:07:42 2025 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) client-ip=208.118.235.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 208.118.235.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 [208.118.235.17]) by mx.zohomail.com with SMTPS id 1533223611635515.4045298504899; Thu, 2 Aug 2018 08:26:51 -0700 (PDT) Received: from localhost ([::1]:46286 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1flFV0-0002Ph-IV for importer@patchew.org; Thu, 02 Aug 2018 11:26:46 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36354) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1flEuB-0002BU-DJ for qemu-devel@nongnu.org; Thu, 02 Aug 2018 10:48:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1flEuA-0008VW-L0 for qemu-devel@nongnu.org; Thu, 02 Aug 2018 10:48:43 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:48770 helo=mx1.redhat.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1flEu8-0008U6-Gt; Thu, 02 Aug 2018 10:48:40 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 03596818F04B; Thu, 2 Aug 2018 14:48:40 +0000 (UTC) Received: from red.redhat.com (ovpn-124-239.rdu2.redhat.com [10.10.124.239]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4EAB010FFE7D; Thu, 2 Aug 2018 14:48:38 +0000 (UTC) From: Eric Blake To: qemu-devel@nongnu.org Date: Thu, 2 Aug 2018 09:48:31 -0500 Message-Id: <20180802144834.520904-2-eblake@redhat.com> In-Reply-To: <20180802144834.520904-1-eblake@redhat.com> References: <20180802144834.520904-1-eblake@redhat.com> X-Scanned-By: MIMEDefang 2.78 on 10.11.54.3 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.8]); Thu, 02 Aug 2018 14:48:40 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.8]); Thu, 02 Aug 2018 14:48:40 +0000 (UTC) for IP:'10.11.54.3' DOMAIN:'int-mx03.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'eblake@redhat.com' RCPT:'' X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 66.187.233.73 Subject: [Qemu-devel] [PATCH 1/4] block: Add bdrv_get_request_alignment() 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 , rjones@redhat.com, qemu-block@nongnu.org, Max Reitz Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail: RDMRC_1 RSF_0 Z_629925259 SPT_0 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" The next patch needs access to a device's minimum permitted alignment, since NBD wants to advertise this to clients. Add an accessor function, borrowing from blk_get_max_transfer() for accessing a backend's block limits. Signed-off-by: Eric Blake Reviewed-by: Vladimir Sementsov-Ogievskiy --- include/sysemu/block-backend.h | 1 + block/block-backend.c | 7 +++++++ 2 files changed, 8 insertions(+) diff --git a/include/sysemu/block-backend.h b/include/sysemu/block-backend.h index 830d873f24f..20f8bbbce37 100644 --- a/include/sysemu/block-backend.h +++ b/include/sysemu/block-backend.h @@ -176,6 +176,7 @@ bool blk_is_available(BlockBackend *blk); void blk_lock_medium(BlockBackend *blk, bool locked); void blk_eject(BlockBackend *blk, bool eject_flag); int blk_get_flags(BlockBackend *blk); +uint32_t blk_get_request_alignment(BlockBackend *blk); uint32_t blk_get_max_transfer(BlockBackend *blk); int blk_get_max_iov(BlockBackend *blk); void blk_set_guest_block_size(BlockBackend *blk, int align); diff --git a/block/block-backend.c b/block/block-backend.c index f2f75a977d7..fb8c827d117 100644 --- a/block/block-backend.c +++ b/block/block-backend.c @@ -1798,6 +1798,13 @@ int blk_get_flags(BlockBackend *blk) } } +/* Returns the minimum request alignment, in bytes; guaranteed nonzero */ +uint32_t blk_get_request_alignment(BlockBackend *blk) +{ + BlockDriverState *bs =3D blk_bs(blk); + return bs ? bs->bl.request_alignment : BDRV_SECTOR_SIZE; +} + /* Returns the maximum transfer length, in bytes; guaranteed nonzero */ uint32_t blk_get_max_transfer(BlockBackend *blk) { --=20 2.14.4 From nobody Sun Oct 5 19:07:42 2025 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) client-ip=208.118.235.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 208.118.235.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 [208.118.235.17]) by mx.zohomail.com with SMTPS id 1533223874711662.4366724608068; Thu, 2 Aug 2018 08:31:14 -0700 (PDT) Received: from localhost ([::1]:46333 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1flFZJ-0006Uq-Dl for importer@patchew.org; Thu, 02 Aug 2018 11:31:13 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36369) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1flEuC-0002CO-6b for qemu-devel@nongnu.org; Thu, 02 Aug 2018 10:48:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1flEuB-0008Vo-AZ for qemu-devel@nongnu.org; Thu, 02 Aug 2018 10:48:44 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:55836 helo=mx1.redhat.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1flEu9-0008UJ-5L; Thu, 02 Aug 2018 10:48:41 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A6B7D4025077; Thu, 2 Aug 2018 14:48:40 +0000 (UTC) Received: from red.redhat.com (ovpn-124-239.rdu2.redhat.com [10.10.124.239]) by smtp.corp.redhat.com (Postfix) with ESMTP id 2C55210CD897; Thu, 2 Aug 2018 14:48:40 +0000 (UTC) From: Eric Blake To: qemu-devel@nongnu.org Date: Thu, 2 Aug 2018 09:48:32 -0500 Message-Id: <20180802144834.520904-3-eblake@redhat.com> In-Reply-To: <20180802144834.520904-1-eblake@redhat.com> References: <20180802144834.520904-1-eblake@redhat.com> X-Scanned-By: MIMEDefang 2.78 on 10.11.54.3 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Thu, 02 Aug 2018 14:48:40 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Thu, 02 Aug 2018 14:48:40 +0000 (UTC) for IP:'10.11.54.3' DOMAIN:'int-mx03.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'eblake@redhat.com' RCPT:'' X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 66.187.233.73 Subject: [Qemu-devel] [PATCH 2/4] nbd/server: Advertise actual minimum block size 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: Paolo Bonzini , rjones@redhat.com, qemu-block@nongnu.org Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail: RDMRC_1 RSF_0 Z_629925259 SPT_0 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Both NBD_CMD_BLOCK_STATUS and structured NBD_CMD_READ will split their reply according to bdrv_block_status() boundaries. If the block device has a request_alignment smaller than 512, but we advertise a block alignment of 512 to the client, then this can result in the server reply violating client expectations by reporting a smaller region of the export than what the client is permitted to address. Thus, it is imperative that we advertise the actual minimum block limit, rather than blindly rounding it up to 512 (bdrv_block_status() cannot return status aligned any smaller than request_alignment). Signed-off-by: Eric Blake --- nbd/server.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/nbd/server.c b/nbd/server.c index ea5fe0eb336..cd3c41f895b 100644 --- a/nbd/server.c +++ b/nbd/server.c @@ -608,10 +608,12 @@ static int nbd_negotiate_handle_info(NBDClient *clien= t, uint16_t myflags, /* Send NBD_INFO_BLOCK_SIZE always, but tweak the minimum size * according to whether the client requested it, and according to * whether this is OPT_INFO or OPT_GO. */ - /* minimum - 1 for back-compat, or 512 if client is new enough. - * TODO: consult blk_bs(blk)->bl.request_alignment? */ - sizes[0] =3D - (client->opt =3D=3D NBD_OPT_INFO || blocksize) ? BDRV_SECTOR_S= IZE : 1; + /* minimum - 1 for back-compat, or actual if client will obey it. */ + if (client->opt =3D=3D NBD_OPT_INFO || blocksize) { + sizes[0] =3D blk_get_request_alignment(exp->blk); + } else { + sizes[0] =3D 1; + } /* preferred - Hard-code to 4096 for now. * TODO: is blk_bs(blk)->bl.opt_transfer appropriate? */ sizes[1] =3D 4096; --=20 2.14.4 From nobody Sun Oct 5 19:07:42 2025 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) client-ip=208.118.235.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 208.118.235.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 [208.118.235.17]) by mx.zohomail.com with SMTPS id 1533223770639581.8158590677566; Thu, 2 Aug 2018 08:29:30 -0700 (PDT) Received: from localhost ([::1]:46307 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1flFXd-0004u2-9H for importer@patchew.org; Thu, 02 Aug 2018 11:29:29 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36401) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1flEuF-0002Fi-0l for qemu-devel@nongnu.org; Thu, 02 Aug 2018 10:48:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1flEuD-000058-9M for qemu-devel@nongnu.org; Thu, 02 Aug 2018 10:48:47 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:43468 helo=mx1.redhat.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1flEu9-0008Uo-Ri; Thu, 02 Aug 2018 10:48:41 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 674B1F2B40; Thu, 2 Aug 2018 14:48:41 +0000 (UTC) Received: from red.redhat.com (ovpn-124-239.rdu2.redhat.com [10.10.124.239]) by smtp.corp.redhat.com (Postfix) with ESMTP id D2A771007083; Thu, 2 Aug 2018 14:48:40 +0000 (UTC) From: Eric Blake To: qemu-devel@nongnu.org Date: Thu, 2 Aug 2018 09:48:33 -0500 Message-Id: <20180802144834.520904-4-eblake@redhat.com> In-Reply-To: <20180802144834.520904-1-eblake@redhat.com> References: <20180802144834.520904-1-eblake@redhat.com> X-Scanned-By: MIMEDefang 2.78 on 10.11.54.3 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Thu, 02 Aug 2018 14:48:41 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Thu, 02 Aug 2018 14:48:41 +0000 (UTC) for IP:'10.11.54.3' DOMAIN:'int-mx03.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'eblake@redhat.com' RCPT:'' X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 66.187.233.73 Subject: [Qemu-devel] [PATCH 3/4] iotests: Add 228 to test NBD on unaligned images 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 , rjones@redhat.com, qemu-block@nongnu.org, Max Reitz Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail: RDMRC_1 RSF_0 Z_629925259 SPT_0 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Add a test for the NBD server fix in the previous patch. In short, when serving a raw POSIX file that is not aligned to sector boundaries, qemu must not split a structured read or block status result any smaller than the block size that it advertised to the client; since qemu as client rejects servers that split up a block status. Not tested yet, but worth adding to this test: an NBD server that can advertise a non-sector-aligned size (such as nbdkit) causes qemu as the NBD client to misbehave when it rounds the size up and accesses beyond the advertised size. Qemu as NBD server never advertises a non-sector-aligned size (since bdrv_getlength() currently rounds up to sector boundaries); until qemu can act as such a server, testing this flaw will have to rely on external binaries. Signed-off-by: Eric Blake --- tests/qemu-iotests/228 | 96 ++++++++++++++++++++++++++++++++++++++++++= ++++ tests/qemu-iotests/228.out | 8 ++++ tests/qemu-iotests/group | 1 + 3 files changed, 105 insertions(+) create mode 100755 tests/qemu-iotests/228 create mode 100644 tests/qemu-iotests/228.out diff --git a/tests/qemu-iotests/228 b/tests/qemu-iotests/228 new file mode 100755 index 00000000000..390fe5f6512 --- /dev/null +++ b/tests/qemu-iotests/228 @@ -0,0 +1,96 @@ +#!/bin/bash +# +# Test qemu-nbd vs. unaligned images +# +# Copyright (C) 2018 Red Hat, Inc. +# +# This program is free software; you can redistribute it and/or modify +# it under the terms of the GNU General Public License as published by +# the Free Software Foundation; either version 2 of the License, or +# (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program. If not, see . +# + +seq=3D"$(basename $0)" +echo "QA output created by $seq" + +here=3D"$PWD" +status=3D1 # failure is the default! + +nbd_unix_socket=3D$TEST_DIR/test_qemu_nbd_socket +rm -f "${TEST_DIR}/qemu-nbd.pid" + +_cleanup_nbd() +{ + local NBD_PID + if [ -f "${TEST_DIR}/qemu-nbd.pid" ]; then + read NBD_PID < "${TEST_DIR}/qemu-nbd.pid" + rm -f "${TEST_DIR}/qemu-nbd.pid" + if [ -n "$NBD_PID" ]; then + kill "$NBD_PID" + fi + fi + rm -f "$nbd_unix_socket" +} + +_wait_for_nbd() +{ + for ((i =3D 0; i < 300; i++)) + do + if [ -r "$nbd_unix_socket" ]; then + return + fi + sleep 0.1 + done + echo "Failed in check of unix socket created by qemu-nbd" + exit 1 +} + +_cleanup() +{ + _cleanup_test_img + _cleanup_nbd +} +trap "_cleanup; exit \$status" 0 1 2 3 15 + +# get standard environment, filters and checks +. ./common.rc +. ./common.filter + +_supported_fmt raw +_supported_proto nbd +_supported_os Linux +_require_command QEMU_NBD + +echo +echo "=3D=3D=3D Exporting unaligned raw image =3D=3D=3D" +echo + +# can't use _make_test_img, because qemu-img rounds image size up, +# and because we want to use Unix socket rather than TCP port. Likewise, +# we have to redirect TEST_IMG to our server. +printf %01000d 0 > "$TEST_IMG_FILE" +_cleanup_nbd +$QEMU_NBD -f $IMGFMT -v -t -k "$nbd_unix_socket" -e 42 -x '' "$TEST_IMG_FI= LE" & +_wait_for_nbd +TEST_IMG=3D"nbd:unix:$nbd_unix_socket" + +$QEMU_IMG map --output=3Djson "$TEST_IMG" | _filter_qemu_img_map +$QEMU_IO -c map "$TEST_IMG" + +# 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. +# However, since qemu as server always rounds up to a sector alignment, +# we would have to use nbdkit to provoke the current client failures. + +# success, all done +echo '*** done' +rm -f $seq.full +status=3D0 diff --git a/tests/qemu-iotests/228.out b/tests/qemu-iotests/228.out new file mode 100644 index 00000000000..057e3732f8c --- /dev/null +++ b/tests/qemu-iotests/228.out @@ -0,0 +1,8 @@ +QA output created by 228 + +=3D=3D=3D Exporting unaligned raw image =3D=3D=3D + +[{ "start": 0, "length": 1000, "depth": 0, "zero": false, "data": true}, +{ "start": 1000, "length": 24, "depth": 0, "zero": true, "data": true}] +1 KiB (0x400) bytes allocated at offset 0 bytes (0x0) +*** done diff --git a/tests/qemu-iotests/group b/tests/qemu-iotests/group index b973dc842d9..5bfe2e246d5 100644 --- a/tests/qemu-iotests/group +++ b/tests/qemu-iotests/group @@ -225,3 +225,4 @@ 225 rw auto quick 226 auto quick 227 auto quick +228 rw auto quick --=20 2.14.4 From nobody Sun Oct 5 19:07:42 2025 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) client-ip=208.118.235.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 208.118.235.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 [208.118.235.17]) by mx.zohomail.com with SMTPS id 1533223539235794.5830012384538; Thu, 2 Aug 2018 08:25:39 -0700 (PDT) Received: from localhost ([::1]:46277 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1flFTu-0001CA-2g for importer@patchew.org; Thu, 02 Aug 2018 11:25:38 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36422) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1flEuG-0002GW-59 for qemu-devel@nongnu.org; Thu, 02 Aug 2018 10:48:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1flEuF-00006B-9v for qemu-devel@nongnu.org; Thu, 02 Aug 2018 10:48:48 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:48774 helo=mx1.redhat.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1flEuA-0008VJ-N6; Thu, 02 Aug 2018 10:48:42 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3AAB1818F03C; Thu, 2 Aug 2018 14:48:42 +0000 (UTC) Received: from red.redhat.com (ovpn-124-239.rdu2.redhat.com [10.10.124.239]) by smtp.corp.redhat.com (Postfix) with ESMTP id 8F91B10F1BE6; Thu, 2 Aug 2018 14:48:41 +0000 (UTC) From: Eric Blake To: qemu-devel@nongnu.org Date: Thu, 2 Aug 2018 09:48:34 -0500 Message-Id: <20180802144834.520904-5-eblake@redhat.com> In-Reply-To: <20180802144834.520904-1-eblake@redhat.com> References: <20180802144834.520904-1-eblake@redhat.com> X-Scanned-By: MIMEDefang 2.78 on 10.11.54.3 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.8]); Thu, 02 Aug 2018 14:48:42 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.8]); Thu, 02 Aug 2018 14:48:42 +0000 (UTC) for IP:'10.11.54.3' DOMAIN:'int-mx03.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'eblake@redhat.com' RCPT:'' X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 66.187.233.73 Subject: [Qemu-devel] [PATCH 4/4] nbd/client: Deal with unaligned size from server 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 , Paolo Bonzini , rjones@redhat.com, qemu-block@nongnu.org, Max Reitz Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail: RDMRC_1 RSF_0 Z_629925259 SPT_0 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" When a server advertises an unaligned size but no block sizes, the code was rounding up to a sector-aligned size (a known limitation of bdrv_getlength()), then assuming a request_alignment of 512 (the recommendation of the NBD spec for maximum portability). However, this means that qemu will actually attempt to access the padding bytes of the trailing partial sector. An easy demonstration, using nbdkit as the server: $ nbdkit -fv random size=3D1023 $ qemu-io -r -f raw -c 'r -v 0 1023' nbd://localhost:10809 read failed: Invalid argument because the client rounded the request up to 1024 bytes, which nbdkit then rejected as beyond the advertised size of 1023. Note that qemu as the server refuses to send an unaligned size, as it has already rounded the unaligned image up to sector size, and then happily resizes the image on access (at least when serving a POSIX file over NBD). Reported-by: Richard W.M. Jones Signed-off-by: Eric Blake Reviewed-by: Vladimir Sementsov-Ogievskiy --- block/nbd.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/block/nbd.c b/block/nbd.c index e87699fb73b..a3e6889c57f 100644 --- a/block/nbd.c +++ b/block/nbd.c @@ -473,7 +473,16 @@ static void nbd_refresh_limits(BlockDriverState *bs, E= rror **errp) uint32_t min =3D s->info.min_block; uint32_t max =3D MIN_NON_ZERO(NBD_MAX_BUFFER_SIZE, s->info.max_block); - bs->bl.request_alignment =3D min ? min : BDRV_SECTOR_SIZE; + /* + * If the server did not advertise an alignment, then pick the + * largest power of 2 that evenly divides the advertised size, but + * does not exceed a sector. + */ + if (!min) { + min =3D 1 << ctz32(BDRV_SECTOR_SIZE | s->info.size); + } + + bs->bl.request_alignment =3D min; bs->bl.max_pdiscard =3D max; bs->bl.max_pwrite_zeroes =3D max; bs->bl.max_transfer =3D max; --=20 2.14.4