[PATCH] 2.4.19 revert block_llseek behavior to standard

[PATCH] 2.4.19 revert block_llseek behavior to standard

[Phil Auld]

Hi Al,
	I think this falls under the VFS umbrella, but I may be wrong. 

Below is a fix to make block_llseek behave as specified in the Single Unix Spec. v3.
(http://www.unix-systems.org/single_unix_specification/). It's extremely trivial but
may have political baggage.

--- fs/block_dev.c.orig	Mon Aug 12 09:23:19 2002
+++ fs/block_dev.c	Mon Aug 12 09:24:06 2002
@@ -175,7 +175,7 @@
 			offset += file->f_pos;
 	}
 	retval = -EINVAL;
-	if (offset >= 0 && offset <= size) {
+	if (offset >= 0) {
 		if (offset != file->f_pos) {
 			file->f_pos = offset;
 			file->f_reada = 0;


Thanks,

Phil

-- 
Philip R. Auld, Ph.D.                  Technical Staff 
Egenera Corp.                        pauld@egenera.com
165 Forest St., Marlboro, MA 01752       (508)858-2600

Re: [PATCH] 2.4.19 revert block_llseek behavior to standard

[Alan Cox]

On Mon, 2002-08-12 at 17:06, Phil Auld wrote:
> Hi Al,
> 	I think this falls under the VFS umbrella, but I may be wrong. 
> 
> Below is a fix to make block_llseek behave as specified in the Single Unix Spec. v3.
> (http://www.unix-systems.org/single_unix_specification/). It's extremely trivial but
> may have political baggage.

Political I don't see any. Technical - have you verified each of our
block drivers behaves correctly when given an offset over its side, and
that it correctly fails on a 32bit block wrap.

I suspect we should still fail it with the allowed error code to be safe
in 2.4

Re: [PATCH] 2.4.19 revert block_llseek behavior to standard

[Phil Auld]

Rumor has it that on Mon, Aug 12, 2002 at 05:20:57PM +0100 Alan Cox said:
> On Mon, 2002-08-12 at 17:06, Phil Auld wrote:
> > Hi Al,
> > 	I think this falls under the VFS umbrella, but I may be wrong. 
> > 
> > Below is a fix to make block_llseek behave as specified in the Single Unix Spec. v3.
> > (http://www.unix-systems.org/single_unix_specification/). It's extremely trivial but
> > may have political baggage.
> 
> Political I don't see any. Technical - have you verified each of our
> block drivers behaves correctly when given an offset over its side, and
> that it correctly fails on a 32bit block wrap.
> 

No, but how did it work prior to 2.4.11?

> I suspect we should still fail it with the allowed error code to be safe
> in 2.4

I may be missing something. How does tying a return of EINVAL to the size
necessarily imply the resulting offset will be negative? There is already 
an explicit test for that.


-- 
Philip R. Auld, Ph.D.                  Technical Staff 
Egenera Corp.                        pauld@egenera.com
165 Forest St., Marlboro, MA 01752       (508)858-2600

Re: [PATCH] 2.4.19 revert block_llseek behavior to standard

[Alan Cox]

On Mon, 2002-08-12 at 17:36, Phil Auld wrote:
> > Political I don't see any. Technical - have you verified each of our
> > block drivers behaves correctly when given an offset over its side, and
> > that it correctly fails on a 32bit block wrap.
> > 
> 
> No, but how did it work prior to 2.4.11?

Did it work correctly - the answer I believe is - no it didnt.


Alan

Re: [PATCH] 2.4.19 revert block_llseek behavior to standard

[Phil Auld]

Rumor has it that on Mon, Aug 12, 2002 at 06:14:08PM +0100 Alan Cox said:
> On Mon, 2002-08-12 at 17:36, Phil Auld wrote:
> > > Political I don't see any. Technical - have you verified each of our
> > > block drivers behaves correctly when given an offset over its side, and
> > > that it correctly fails on a 32bit block wrap.
> > > 
> > 
> > No, but how did it work prior to 2.4.11?
> 
> Did it work correctly - the answer I believe is - no it didnt.
> 

Fair enough. The higher level fix is a band-aid over bugs in some of 
the lower level drivers. 

Thanks for the info. I didn't think that patch would go anywhere,
but it did help explain why the change. 

Phil

> 
> Alan

-- 
Philip R. Auld, Ph.D.                  Technical Staff 
Egenera Corp.                        pauld@egenera.com
165 Forest St., Marlboro, MA 01752       (508)858-2600

Re: [PATCH] 2.4.19 revert block_llseek behavior to standard

[Alan Cox]

On Mon, 2002-08-12 at 18:57, Phil Auld wrote
> > Did it work correctly - the answer I believe is - no it didnt.
> > 
> 
> Fair enough. The higher level fix is a band-aid over bugs in some of 
> the lower level drivers. 
> 
> Thanks for the info. I didn't think that patch would go anywhere,
> but it did help explain why the change. 

Do push it for 2.5 - there we have time to find out what it exposes

Re: [PATCH] 2.4.19 revert block_llseek behavior to standard

[Phil Auld]

Rumor has it that on Mon, Aug 12, 2002 at 07:06:06PM +0100 Alan Cox said:
> On Mon, 2002-08-12 at 18:57, Phil Auld wrote
> > > Did it work correctly - the answer I believe is - no it didnt.
> > > 
> > 
> > Fair enough. The higher level fix is a band-aid over bugs in some of 
> > the lower level drivers. 
> > 
> > Thanks for the info. I didn't think that patch would go anywhere,
> > but it did help explain why the change. 
> 
> Do push it for 2.5 - there we have time to find out what it exposes
> 

I sent out a 2.5.31 version as well, although I muffed Al Viro's address. 
I don't know if it really falls under his domain anyway...

Thanks,


Phil

-- 
Philip R. Auld, Ph.D.                  Technical Staff 
Egenera Corp.                        pauld@egenera.com
165 Forest St., Marlboro, MA 01752       (508)858-2600

Re: [PATCH] 2.4.19 revert block_llseek behavior to standard

[Phil Auld]

Rumor has it that on Mon, Aug 12, 2002 at 06:14:08PM +0100 Alan Cox said:
> On Mon, 2002-08-12 at 17:36, Phil Auld wrote:
> > > Political I don't see any. Technical - have you verified each of our
> > > block drivers behaves correctly when given an offset over its side, and
> > > that it correctly fails on a 32bit block wrap.
> > > 
> > 
> > No, but how did it work prior to 2.4.11?
> 
> Did it work correctly - the answer I believe is - no it didnt.
> 
> 

It may not have worked in all cases but it did observe standard 
specified behavior.

Phil


> Alan

-- 
Philip R. Auld, Ph.D.                  Technical Staff 
Egenera Corp.                        pauld@egenera.com
165 Forest St., Marlboro, MA 01752       (508)858-2600

Re: [PATCH] 2.4.19 revert block_llseek behavior to standard

[Christoph Hellwig]

On Mon, Aug 12, 2002 at 12:06:59PM -0400, Phil Auld wrote:
> Hi Al,
> 	I think this falls under the VFS umbrella, but I may be wrong. 
> 
> Below is a fix to make block_llseek behave as specified in the Single Unix Spec. v3.
> (http://www.unix-systems.org/single_unix_specification/). It's extremely trivial but
> may have political baggage.

Have you tested when you actually seek over the size of a block device?
Stupid standards aside: what is the purpose of this?  blockdevices won't
grow bigger if you seek beyond them..

Did any Linux implementation ever follow the standard (as you rewrite
reverse)?  What's the behaviour of other unix systems when seeking
beyond the end of block devices?

Re: [PATCH] 2.4.19 revert block_llseek behavior to standard

[Phil Auld]

Rumor has it that on Mon, Aug 12, 2002 at 05:46:34PM +0100 Christoph Hellwig said:
> On Mon, Aug 12, 2002 at 12:06:59PM -0400, Phil Auld wrote:
> > Hi Al,
> > 	I think this falls under the VFS umbrella, but I may be wrong. 
> > 
> > Below is a fix to make block_llseek behave as specified in the Single Unix Spec. v3.
> > (http://www.unix-systems.org/single_unix_specification/). It's extremely trivial but
> > may have political baggage.
> 
> Have you tested when you actually seek over the size of a block device?

Yes. Later reads/writes fails as they should.

> Stupid standards aside: what is the purpose of this? blockdevices don't

It can be used to determine the size fo the device. Seek then read, if read fails
back off. That's where I first noticed it. The IOtest program from the Cerberus suite
does this.

As to the stupidity of standards, I'm not sure how to answer that. I am not the only
one to raise this issue though. 

> grow bigger if you seek beyond them..
> 
> Did any Linux implementation ever follow the standard (as you rewrite
> reverse)? 

Yes. As far as I can tell this came in in 2.4.11. Earlier 2.4 kernels and at least 2.2.16 
(I didn't check them all) don't have this problem. If it had always been this way it
probably wouldn't have come up. I'm not trying to pick nits on purpose. Something
used to work and then didn't.  

> What's the behaviour of other unix systems when seeking
> beyond the end of block devices?

Unfortunately (or not), I don't have any others handy. 

Remember there is no data transfer taking place to do the lseek.

There were a couple of exerpts from the standard in this thread:
http://marc.theaimsgroup.com/?l=linux-kernel&m=102889752209363&w=2



-- 
Philip R. Auld, Ph.D.                  Technical Staff 
Egenera Corp.                        pauld@egenera.com
165 Forest St., Marlboro, MA 01752       (508)858-2600

Re: [PATCH] 2.4.19 revert block_llseek behavior to standard

[Helge Hafting]

Christoph Hellwig wrote:
> 
> On Mon, Aug 12, 2002 at 12:06:59PM -0400, Phil Auld wrote:
> > Hi Al,
> >       I think this falls under the VFS umbrella, but I may be wrong.
> >
> > Below is a fix to make block_llseek behave as specified in the Single Unix Spec. v3.
> > (http://www.unix-systems.org/single_unix_specification/). It's extremely trivial but
> > may have political baggage.
> 
> Have you tested when you actually seek over the size of a block device?
> Stupid standards aside: what is the purpose of this?  blockdevices won't
> grow bigger if you seek beyond them..
> 
True for a disk - but will all blockdevices be
like that forever?
Extending a ram disk might be useful.  Or something
looped to a regular file.  

Helge Hafting

Re: [PATCH] 2.4.19 revert block_llseek behavior to standard

[Peter Chubb]

>>>>> "Christoph" == Christoph Hellwig <hch@infradead.org> writes:

Christoph>   What's the behaviour of other unix
Christoph> systems when seeking beyond the end of block devices? 

The seek succeeds; 

On a disc-like device, attempts to write at that offset return -1 EFBIG;
the first attempt to read at that offset returns 0; subequent ones
return -1 and ENXIO.

After the seek, lseek(fd, 0, SEEK_CURRENT) returns the (after end of
file) current offset.

At least for the ones I've been able to test on (UNIXWare, Solaris).


--
Dr Peter Chubb				    peterc@gelato.unsw.edu.au
You are lost in a maze of BitKeeper repositories, all almost the same.