From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45517) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1adfZc-0003fE-0K for qemu-devel@nongnu.org; Wed, 09 Mar 2016 09:58:52 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1adfZb-00029t-5K for qemu-devel@nongnu.org; Wed, 09 Mar 2016 09:58:51 -0500 Date: Wed, 9 Mar 2016 15:58:37 +0100 From: Kevin Wolf Message-ID: <20160309145837.GI5205@noname.redhat.com> References: <20160309121139.GA21975@aepfle.de> <56E0173C.70407@redhat.com> <20160309144514.GA29027@aepfle.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160309144514.GA29027@aepfle.de> Subject: Re: [Qemu-devel] bogus bdrv_check_request in bdrv_co_discard List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Olaf Hering Cc: Paolo Bonzini , qemu-block@nongnu.org, qemu-devel@nongnu.org, Stefan Hajnoczi Am 09.03.2016 um 15:45 hat Olaf Hering geschrieben: > On Wed, Mar 09, Paolo Bonzini wrote: > > > It probably should range check max_unmap_size and max_io_size against > > BDRV_REQUEST_MAX_SECTORS, and reject anything bigger than that, though. > > Are you sure? Shouldnt the only check be if sect+num is inside the disk > size? And everything smaller should be automatically split by qemu to > whatever num. > > I will see what works for me, probably something like this is already enough > (for 2.0.2): > > --- xen-4.5.2-testing.orig/tools/qemu-xen-dir-remote/block.c > +++ xen-4.5.2-testing/tools/qemu-xen-dir-remote/block.c > @@ -4898,7 +4898,8 @@ int coroutine_fn bdrv_co_discard(BlockDr > > if (!bs->drv) { > return -ENOMEDIUM; > - } else if (bdrv_check_request(bs, sector_num, nb_sectors)) { > + } else if (bdrv_check_byte_request(bs, sector_num * BDRV_SECTOR_SIZE, > + nb_sectors * BDRV_SECTOR_SIZE)) { > return -EIO; Removing integer overflow checks without removing the potentially overflowing operation doesn't feel like a particularly good idea, though. Kevin