[lkml]   [2002]   [Jul]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] vfs_read/vfs_write small bug fix (2.5.29)
Linus Torvalds <> 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 Schwab, SuSE Labs,
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."
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:22    [W:0.065 / U:1.364 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site