linux-kernel - Re: [PATCH 1/2] fs: add SEEK_HOLE and SEEK

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <4DB597E3.7090600@redhat.com>
Date:	Mon, 25 Apr 2011 09:48:51 -0600
From:	Eric Blake <eblake@...hat.com>
To:	Nick Bowler <nbowler@...iptictech.com>
CC:	Markus Trippelsdorf <markus@...ppelsdorf.de>,
	Christoph Hellwig <hch@...radead.org>,
	Josef Bacik <josef@...icpanda.com>,
	linux-kernel@...r.kernel.org, linux-btrfs@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, Coreutils <coreutils@....org>
Subject: Re: [PATCH 1/2] fs: add SEEK_HOLE and SEEK_DATA flags

On 04/25/2011 09:02 AM, Nick Bowler wrote:

Hi Nick,
> * File A (sparse file created by lseek/write beyond end-of-file):
> 
>     data | hole 0 | data || hole 1 (virtual)
> 
> * File B (sparse file created by truncate beyond end-of-file):
> 
>     data | hole 0 || hole 1 (virtual)
> 
> Excluding the error description, the term "the last hole" is used in
> two places in your proposal:
> 
>   * (for SEEK_HOLE): if offset falls within "the last hole", then the
>     file offset may be set to the file size instead.
> 
>   * (for SEEK_DATA): it shall be an error ... if offset falls within the
>     last hole.
> 
> I imagine that both of these conditions are intended to address the
> case where the offset falls within hole 0 in File B, that is, when
> there is no non-hole data beyond the specified offset but the offset
> is nevertheless less than the file size.

Correct.

>  However, this looks (to me)
> like the penultimate hole in the file, not the last hole.  Furthermore,
> these conditions are presumably *not* intended to apply to the
> penultimate hole in File A, which has data after it.

Good catch.

> 
> I think my confusion can be avoided by talking about the last non-hole
> data byte in the file (which is unambigious), instead of by talking
> about the last hole.  For instance, the SEEK_HOLE/SEEK_DATA descriptions
> could be written as follows:
> 
>   If whence is SEEK_HOLE, the file offset shall be set to the smallest
>   location of a byte within a hole and not less than offset, except that
>   if offset falls beyond the last byte not within a hole, then the file
>   offset may be set to the file size instead.  It shall be an error if
>   offset is greater or equal to the size of the file.
> 
>   If whence is SEEK_DATA, the file offset shall be set to the smallest
>   location of a byte not within a hole and not less than offset.  It shall
>   be an error if no such byte exists.
> 
> plus a corresponding update to the ENXIO description:
> 
>   ... or the whence argument is SEEK_DATA and the offset falls beyond
>   the last byte not within a hole.

I've added your improved wording as a comment at
http://austingroupbugs.net/view.php?id=415

-- 
Eric Blake   eblake@...hat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org


Download attachment "signature.asc" of type "application/pgp-signature" (620 bytes)