From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52322) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bFM4Q-00048S-I9 for qemu-devel@nongnu.org; Tue, 21 Jun 2016 09:50:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bFM4O-0001At-MU for qemu-devel@nongnu.org; Tue, 21 Jun 2016 09:50:25 -0400 Date: Tue, 21 Jun 2016 15:50:15 +0200 From: Kevin Wolf Message-ID: <20160621135015.GG4520@noname.redhat.com> References: <1465939839-30097-1-git-send-email-eblake@redhat.com> <1465939839-30097-15-git-send-email-eblake@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1465939839-30097-15-git-send-email-eblake@redhat.com> Subject: Re: [Qemu-devel] [PATCH v2 14/17] block: Switch transfer length bounds to byte-based List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org, Max Reitz , Stefan Hajnoczi , Fam Zheng , Ronnie Sahlberg , Paolo Bonzini , Peter Lieven , "Michael S. Tsirkin" Am 14.06.2016 um 23:30 hat Eric Blake geschrieben: > Sector-based limits are awkward to think about; in our on-going > quest to move to byte-based interfaces, convert max_transfer_length > and opt_transfer_length. Rename them (dropping the _length suffix) > so that the compiler will help us catch the change in semantics > across any rebased code, and improve the documentation. Use unsigned > values, so that we don't have to worry about negative values and > so that bit-twiddling is easier; however, we are still constrained > by 2^31 of signed int in most APIs. > > Signed-off-by: Eric Blake > @@ -1738,8 +1742,8 @@ static void iscsi_refresh_limits(BlockDriverState *bs, Error **errp) > } else { > bs->bl.pwrite_zeroes_alignment = iscsilun->block_size; > } > - bs->bl.opt_transfer_length = > - sector_limits_lun2qemu(iscsilun->bl.opt_xfer_len, iscsilun); > + assert(iscsilun->bl.opt_xfer_len < INT_MAX / iscsilun->block_size); > + bs->bl.opt_transfer = iscsilun->bl.opt_xfer_len * iscsilun->block_size; > } iscsilun->bl.opt_xfer_len comes directly from libiscsi, and presumably from the iscsi server, without being checked or sanitised. I don't think we can assert a specific range of values for it but must assume that it can be any uint32_t. We can return an error for a device with a value that we don't like (even though using the maximum might be just fine), but crashing qemu is not an option. > diff --git a/block/raw-posix.c b/block/raw-posix.c > index aacf132..f2bea85 100644 > --- a/block/raw-posix.c > +++ b/block/raw-posix.c > @@ -752,7 +752,8 @@ static void raw_refresh_limits(BlockDriverState *bs, Error **errp) > if (S_ISBLK(st.st_mode)) { > int ret = hdev_get_max_transfer_length(s->fd); > if (ret >= 0) { > - bs->bl.max_transfer_length = ret; > + assert(ret <= BDRV_REQUEST_MAX_SECTORS); > + bs->bl.max_transfer = ret << BDRV_SECTOR_BITS; > } > } > } Same thing here. Kevin