From patchwork Wed Apr 3 03:05:19 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Eric Blake X-Patchwork-Id: 10882611 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 61AAE139A for ; Wed, 3 Apr 2019 03:07:20 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 4903928950 for ; Wed, 3 Apr 2019 03:07:20 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 3D1DE289D2; Wed, 3 Apr 2019 03:07:20 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI autolearn=ham version=3.3.1 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id D43A228950 for ; Wed, 3 Apr 2019 03:07:19 +0000 (UTC) Received: from localhost ([127.0.0.1]:40598 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hBWFD-0001wU-5Q for patchwork-qemu-devel@patchwork.kernel.org; Tue, 02 Apr 2019 23:07:19 -0400 Received: from eggs.gnu.org ([209.51.188.92]:41647) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hBWDX-0000C5-Ks for qemu-devel@nongnu.org; Tue, 02 Apr 2019 23:05:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hBWDW-0004sl-Hm for qemu-devel@nongnu.org; Tue, 02 Apr 2019 23:05:35 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38794) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hBWDU-0004f8-0P; Tue, 02 Apr 2019 23:05:32 -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 3AC5E30832EB; Wed, 3 Apr 2019 03:05:30 +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 6495019C57; Wed, 3 Apr 2019 03:05:27 +0000 (UTC) From: Eric Blake To: qemu-devel@nongnu.org Date: Tue, 2 Apr 2019 22:05:19 -0500 Message-Id: <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.44]); Wed, 03 Apr 2019 03:05:30 +0000 (UTC) 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 for-4.0? 0/7] Final round of NBD alignment fixes 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: vsementsov@virtuozzo.com, jsnow@redhat.com, qemu-block@nongnu.org Errors-To: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org Sender: "Qemu-devel" X-Virus-Scanned: ClamAV using ClamSMTP My recent pull request for -rc2 documented several places where our server still does not comply with the NBD specification with regards to alignment. This series finishes the work in making everything compliant, insofar as I could test. The first three patches are rather trivial - they don't drive -rc3 on their own, but are worth having if there is another patch that we want in 4.0 (oh, and I need to fix the missing space in nbd/client's error message in commit 3add3ab7, also in that same category but not posted here). Patch 4 is as close as I can get to demonstrating the remaining alignment bugs in existing qemu (the test passes on current master, but fails if you revert the client workarounds, and then passes again once you apply the tail of this series to fix the server noncompliance). (Viewing traces is a lot more informative than running iotests when it comes to diagnosing protocol compliance issues, although it is also a lot slower and more verbose). Again, not something to drive -rc3 on its own, but worth having if we want the rest. Patches 5-6 fix the most common cases of bad server alignments, but does so by changing a fundamental algorithm in io.c:bdrv_co_block_status() - any time we grab block status by deferral with BDRV_BLOCK_RAW, we want to ensure that the lower layer status is aligned to the requirements of the upper layer. While it passed iotests for me, I'm very much on the fence as to whether this is 4.0 material as a bug fix, or whether we declare that because the alignment bugs are not a regression over 3.1, we save the patch until 4.1. Patch 7 is definitely not 4.0 material - it fixes a bug that I could not provoke in practice, without applying other patches to let NBD exports see through blkdebug (Max's series to fix filter handling will presumably be applied for 4.1, at which point patch 7 should be rebased on top of those patches). Eric Blake (7): nbd/server: Fix blockstatus trace nbd/server: Trace server noncompliance on unaligned requests nbd/server: Don't fail NBD_OPT_INFO for byte-aligned sources iotests: Update 241 to expose backing layer fragmentation block: Fix BDRV_BLOCK_RAW status to honor alignment nbd/server: Avoid unaligned read/block_status from backing nbd/server: Avoid unaligned dirty-bitmap status include/block/block.h | 2 + block/io.c | 155 +++++++++++++++++++++++++++++++++++-- nbd/server.c | 88 +++++++++++++++------ nbd/trace-events | 1 + tests/qemu-iotests/221 | 10 +++ tests/qemu-iotests/221.out | 6 ++ tests/qemu-iotests/241 | 20 ++++- tests/qemu-iotests/241.out | 12 ++- 8 files changed, 258 insertions(+), 36 deletions(-)