Re: [PATCH] vfs_read/vfs_write small bug fix (2.5.29)

[Linus Torvalds]

On 29 Jul 2002, Paul Larson wrote:
> > 
> > (Or maybe glibc doesn't know that the kernel pread/pwrite system calls 
> > were always 64-bit clean, and it just happened to work).
?
> No, with just this patch it still fails on pread02 and pwrite02.

Ok, that just means that it's a library issue now - having looked at
historical kernel behaviour (and a lot of 64/bit architectures emulating
their old 32/bit system calls), the kernel system call interface is
clearly a 64-bit value, ie the kernel only export pread64/pwrite64, not a
"traditional" pread/pwrite at all.

So the question is what the library should do with a 32-bit negative 
"offset_t" passed in to the user-level "pread()" implementation. 

Looking at the disassembly of glibc pread, the implementation seems to be 
to just clear %edx on x86 (which are the high bits of the 64-bit offset 
value passed into sys_pread64()). 

And equally clearly your test wants to get EINVAL.

Your test would pass if glibc just sign-extended the 32-bit value to 64 
bits, instead of zero-extending it.

Alternativealy, your test would pass if glibc just internally checked for 
a negative offset.

I think the sign-extending sounds like the right idea, but that will
obviously break applications that _want_ to pread() in the 2GB-4GB address
without using pread64(). Something that sounds unlikely to be an issue, of
course (and which should have failed with -EBIG at open time anyway)

		Linus