From nobody Sun Oct 5 20:55:06 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