Re: 2.4.18 kernel lseek() bug

[Andreas Dilger <adilger@clusterfs.com>]

On Jun 14, 2002  15:07 +0200, Tomaz Susnik wrote:
> [1] 	Problem description 
> ----------------------------------
> 
>  	a call to lseek() fails with EINVAL under the following conditions:
> 		- it is called on a disk device file
> 		- required offset is larger than the target disk device size

Is this behaviour mandated in a standard, or is it just different from
previous behaviour?  I'm not saying it _isn't_ a bug, but I don't see
how seeking past the end of a block device is very useful.

> 	Attempting to seek through file /dev/hda3 
> 
> 	lseek(6 Gb     ): errno = 0 ret = 6442450944
> 	lseek(7 Gb     ): errno = 0 ret = 7516192768
> 	lseek(8 Gb     ): errno = 0 ret = 8589934592
> 	lseek(9 Gb     ): errno = 0 ret = 9663676416
> 
> 	
> 	Sample output on the same machine, but booted with kernel 2.4.18:
> 
> 	Attempting to seek through file /dev/hda3 
> 
> 	lseek(6 Gb     ): errno = 0 ret = 6442450944
> 	lseek(7 Gb     ): errno = 0 ret = 7516192768
> 	lseek(8 Gb     ): errno = 22 ret = -1
> 	lseek(9 Gb     ): errno = 22 ret = -1
> 
> [6] 	Reason for reporting this problem
> ---------------------------------------------------
> 	Our multi-platform backup product relies on proper behaviour of the
> lseek() command to calculate a rawdisk size.

Well, e2fsprogs has a similar test that it uses if the BLKGETSZ ioctl
fails, but I don't see how this new behaviour is a real problem.  All you
have to do is check if _either_ lseek(offset) fails or read() from that
offset fails to know you are past the end of the block device.  It hardly
changes the algorithm at all.

Cheers, Andreas
--
Andreas Dilger
http://www-mddsp.enel.ucalgary.ca/People/adilger/
http://sourceforge.net/projects/ext2resize/