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

[Andreas Schwab <schwab@suse.de>]

Linus Torvalds <torvalds@transmeta.com> writes:

|> 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.

Yes, this was a bug in glibc, it has been fixed already in CVS.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."