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)
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/