From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43705) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XqJcb-0005jY-8e for qemu-devel@nongnu.org; Mon, 17 Nov 2014 05:33:31 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XqJcQ-0007zK-P1 for qemu-devel@nongnu.org; Mon, 17 Nov 2014 05:33:25 -0500 Received: from mx1.redhat.com ([209.132.183.28]:44696) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XqJcQ-0007z6-CU for qemu-devel@nongnu.org; Mon, 17 Nov 2014 05:33:14 -0500 Message-ID: <5469CEE4.9080900@redhat.com> Date: Mon, 17 Nov 2014 11:33:08 +0100 From: Max Reitz MIME-Version: 1.0 References: <1416219514-22530-1-git-send-email-armbru@redhat.com> <1416219514-22530-4-git-send-email-armbru@redhat.com> In-Reply-To: <1416219514-22530-4-git-send-email-armbru@redhat.com> Content-Type: text/plain; charset=iso-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v3 for-2.2 3/3] raw-posix: The SEEK_HOLE code is flawed, rewrite it List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster , qemu-devel@nongnu.org Cc: kwolf@redhat.com, famz@redhat.com, tony@bakeyournoodle.com, stefanha@redhat.com, pbonzini@redhat.com On 2014-11-17 at 11:18, Markus Armbruster wrote: > On systems where SEEK_HOLE in a trailing hole seeks to EOF (Solaris, > but not Linux), try_seek_hole() reports trailing data instead. > > Additionally, unlikely lseek() failures are treated badly: > > * When SEEK_HOLE fails, try_seek_hole() reports trailing data. For > -ENXIO, there's in fact a trailing hole. Can happen only when > something truncated the file since we opened it. > > * When SEEK_HOLE succeeds, SEEK_DATA fails, and SEEK_END succeeds, > then try_seek_hole() reports a trailing hole. This is okay only > when SEEK_DATA failed with -ENXIO (which means the non-trailing hole > found by SEEK_HOLE has since become trailing somehow). For other > failures (unlikely), it's wrong. > > * When SEEK_HOLE succeeds, SEEK_DATA fails, SEEK_END fails (unlikely), > then try_seek_hole() reports bogus data [-1,start), which its caller > raw_co_get_block_status() turns into zero sectors of data. Could > theoretically lead to infinite loops in code that attempts to scan > data vs. hole forward. > > Rewrite from scratch, with very careful comments. > > Signed-off-by: Markus Armbruster > --- > block/raw-posix.c | 111 +++++++++++++++++++++++++++++++++++++++++------------- > 1 file changed, 85 insertions(+), 26 deletions(-) Reviewed-by: Max Reitz