Am 13.11.2014 um 11:17 hat Markus Armbruster geschrieben:
> When SEEK_HOLE tells us we're in a hole, we try SEEK_DATA to find its
> end. When that fails, we pretend the hole extends to the end of file.
> Wrong.
Wrong only in some cases, see below.
> Except when SEEK_END fails, we screw up and claim it extends
> to offset -1. More wrong.
>
> Fortunately, these seeks are very unlikely to fail. Fix it anyway, by
> returning failure. The caller will then pretend there are no holes.
> Inaccurate, but safe.
>
> Signed-off-by: Markus Armbruster <arm...@redhat.com>
> ---
> block/raw-posix.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/block/raw-posix.c b/block/raw-posix.c
> index fd80d84..2a12a50 100644
> --- a/block/raw-posix.c
> +++ b/block/raw-posix.c
> @@ -1494,8 +1494,9 @@ static int try_seek_hole(BlockDriverState *bs, off_t
> start, off_t *data,
> } else {
> /* On a hole. We need another syscall to find its end. */
> *data = lseek(s->fd, start, SEEK_DATA);
> - if (*data == -1) {
> - *data = lseek(s->fd, 0, SEEK_END);
> + if (*data < 0) {
> + /* no idea where the hole ends, give up (unlikely to happen) */
Not quite unlikely. If the file ends with a sparse area, we'll get
-1/ENXIO here.
lseek() with SEEK_DATA starting in a hole when there is no data until
EOF is actually the part that isn't documented in the man page, but
ENXIO is what I'm seeing here on RHEL 7.
> + return -errno;
> }
> }
Kevin
