linux-kernel - Re: [PATCH 1/2 v2] 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <15392.1304535887@localhost>
Date:	Wed, 04 May 2011 15:04:47 -0400
From:	Valdis.Kletnieks@...edu
To:	Josef Bacik <josef@...hat.com>
Cc:	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	linux-btrfs@...r.kernel.org
Subject: Re: [PATCH 1/2 v2] fs: add SEEK_HOLE and SEEK_DATA flags

On Wed, 04 May 2011 13:58:39 EDT, Josef Bacik said:

> -SEEK_HOLE: this moves the file pos to the nearest hole in the file from the
> given position. 

Nearest, or next? Solaris defines it as "next", for a good reason - otherwise
you can get stuck in a case where the "nearest" hole is back towards the
start of the file - and "seek data" will bounce back to the next byte at
the other end of the hole.

Consider a file with this layout:

< 40K of data>  A  < 32K hole> B < 32K data> C < 8K hole> D <32K data> E ....

If you're in the range between "8K-1 before C" and "8K-1 after D", there's no
application of seeks to "nearest" data/hole that doesn't leave you oscillating
between C and D, and unable to reach B or E.  If youre at C, "nearest hole" is
where you are, and "nearest data" is at D, not B. Similarly for D - nearest
data is C, not E.

However, this is easily dealt with if you define it as "next", as then it is
simple to discover exactly where A/B/C/D/E are.

Content of type "application/pgp-signature" skipped