From patchwork Tue Jun 14 21:30:27 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Eric Blake X-Patchwork-Id: 9177001 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 00CE2604DB for ; Tue, 14 Jun 2016 21:45:16 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id CB4EA28334 for ; Tue, 14 Jun 2016 21:45:16 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id BFC6D28339; Tue, 14 Jun 2016 21:45:16 +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=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 7826628334 for ; Tue, 14 Jun 2016 21:45:16 +0000 (UTC) Received: from localhost ([::1]:38371 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bCw95-0003tn-JJ for patchwork-qemu-devel@patchwork.kernel.org; Tue, 14 Jun 2016 17:45:15 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58217) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bCvvO-00072i-T6 for qemu-devel@nongnu.org; Tue, 14 Jun 2016 17:31:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bCvvM-0006rk-T5 for qemu-devel@nongnu.org; Tue, 14 Jun 2016 17:31:05 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38884) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bCvvF-0006mV-CW; Tue, 14 Jun 2016 17:30:57 -0400 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 018B7C049D68; Tue, 14 Jun 2016 21:30:57 +0000 (UTC) Received: from red.redhat.com (ovpn-116-106.phx2.redhat.com [10.3.116.106]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u5ELUl7D019211; Tue, 14 Jun 2016 17:30:56 -0400 From: Eric Blake To: qemu-devel@nongnu.org Date: Tue, 14 Jun 2016 15:30:27 -0600 Message-Id: <1465939839-30097-6-git-send-email-eblake@redhat.com> In-Reply-To: <1465939839-30097-1-git-send-email-eblake@redhat.com> References: <1465939839-30097-1-git-send-email-eblake@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Tue, 14 Jun 2016 21:30:57 +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 v2 05/17] nbd: Advertise realistic limits to block layer 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: kwolf@redhat.com, Paolo Bonzini , qemu-block@nongnu.org, Max Reitz Errors-To: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org Sender: "Qemu-devel" X-Virus-Scanned: ClamAV using ClamSMTP We were basing the advertisement of maximum discard and transfer length off of UINT32_MAX, but since the rest of the block layer has signed int limits on a transaction, nothing could ever reach that maximum, and we risk overflowing an int once things are converted to byte-based rather than sector-based limits. What's more, we DO have a much smaller limit: both the current kernel and qemu-nbd have a hard limit of 32M on a read or write transaction, and while they may also permit up to a full 32 bits on a discard transaction, the upstream NBD protocol is proposing wording that without any explicit advertisement otherwise, clients should limit ALL requests to the same limits as read and write, even though the other requests do not actually require as many bytes across the wire. So the better limit to tell the block layer is 32M for both values. Signed-off-by: Eric Blake Acked-by: Paolo Bonzini Reviewed-by: Fam Zheng Reviewed-by: Stefan Hajnoczi --- v2: new patch --- block/nbd.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/block/nbd.c b/block/nbd.c index 6015e8b..bf67c8a 100644 --- a/block/nbd.c +++ b/block/nbd.c @@ -362,8 +362,8 @@ static int nbd_co_flush(BlockDriverState *bs) static void nbd_refresh_limits(BlockDriverState *bs, Error **errp) { - bs->bl.max_discard = UINT32_MAX >> BDRV_SECTOR_BITS; - bs->bl.max_transfer_length = UINT32_MAX >> BDRV_SECTOR_BITS; + bs->bl.max_discard = NBD_MAX_SECTORS; + bs->bl.max_transfer_length = NBD_MAX_SECTORS; } static int nbd_co_discard(BlockDriverState *bs, int64_t sector_num,