From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40708) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XhCoP-0002TN-OA for qemu-devel@nongnu.org; Thu, 23 Oct 2014 03:28:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XhCoJ-0000Hm-8k for qemu-devel@nongnu.org; Thu, 23 Oct 2014 03:27:57 -0400 Received: from mx1.redhat.com ([209.132.183.28]:6044) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XhCoJ-0000Hd-0Z for qemu-devel@nongnu.org; Thu, 23 Oct 2014 03:27:51 -0400 Message-ID: <5448ADF2.5010100@redhat.com> Date: Thu, 23 Oct 2014 09:27:46 +0200 From: Max Reitz MIME-Version: 1.0 References: <1413993434-11816-1-git-send-email-mreitz@redhat.com> <1413993434-11816-2-git-send-email-mreitz@redhat.com> <5447E1F6.4040302@redhat.com> In-Reply-To: <5447E1F6.4040302@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v3 1/3] raw-posix: Fix raw_co_get_block_status() after EOF List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake , qemu-devel@nongnu.org Cc: Kevin Wolf , =?UTF-8?B?QmVub8OudCBDYW5ldA==?= , Stefan Hajnoczi On 2014-10-22 at 18:57, Eric Blake wrote: > On 10/22/2014 09:57 AM, Max Reitz wrote: >> As its comment states, raw_co_get_block_status() should unconditionally >> return 0 and set *pnum to 0 for after EOF. >> >> An assertion after lseek(..., SEEK_HOLE) tried to catch this case by >> asserting that errno != -ENXIO (which would indicate a position after >> the EOF); but it should be errno != ENXIO instead. Regardless of that, >> there should be no such assertion at all. If bdrv_getlength() returned >> an outdated value and the image has been resized outside of qemu, >> lseek() will return with errno == ENXIO. Just return that value as an >> error then. >> >> Setting *pnum to 0 and returning 0 should not be done here, as in that >> case we should update the device length as well. So, from qemu's >> perspective, the file has not been resized; it's just that there was an >> error querying sectors beyond a certain point (the actual file size). >> >> Additionally, nb_sectors should be clamped against the image end. This >> was probably not an issue if FIEMAP or SEEK_HOLE/SEEK_DATA worked, but >> the fallback did not take this case into account. >> >> Reported-by: Kevin Wolf >> Signed-off-by: Max Reitz >> --- >> block/raw-posix.c | 14 ++++++++++---- >> 1 file changed, 10 insertions(+), 4 deletions(-) > Reviewed-by: Eric Blake > >> + if (total_size < 0) { >> + return total_size; >> + } else if (start >= total_size) { >> + *pnum = 0; >> + return 0; >> + } else if (start + nb_sectors * BDRV_SECTOR_SIZE > total_size) { >> + nb_sectors = (total_size - start) / BDRV_SECTOR_SIZE; > Should this round up instead of truncate? But it would only matter for > a file size that is not a multiple of sectors, where we probably have > other issues, and where reporting just the full sectors also seems > reasonable. There already was a series (as far as I remember) that somehow tried to make all or at least some block drivers compatible with sizes which are not a multiple of the sector size, so I shouldn't be nullifying that work. Will use ROUND_UP(). Max