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

Linus Torvalds (torvalds@transmeta.com)
Mon, 29 Jul 2002 15:17:32 -0700 (PDT)


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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/