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