Re: [WIP] BZ #14362: POSIX vs. BSD and the `ioctl' interface.

[Chris Metcalf <cmetcalf at tilera dot com>]

On 7/26/2012 6:41 PM, Roland McGrath wrote:
> [Note I changed the Subject: line because it unhelpfully had the wrong BZ#.]
>
>> The problem is that for kernels not configured with HAVE_SYSCALL_WRAPPERS,
>> calling ioctl() with a value that has bit 31 set will result in a value
>> that does not compare equal within the kernel:  the passed-in value will
>> have zero high bits (since the ioctl argument was prototyped as a long) but
>> the kernel constant that the comparison is done against will be
>> sign-extended (since it's prototyped as an int).  So the comparison fails. 
>> This is true for both tilegx and mipsn64 as far as I know.
> In http://sourceware.org/bugzilla/show_bug.cgi?id=14362#c5 Linus claims
> that the kernel uses 'unsigned int' everywhere for ioctl requests.
> If that is so, then there should be no such problem.
> If it's not so, please educate Linus about his error.

Linus writes "You don't see this on Linux, because 64-bit Linux will
correctly truncate the request value to 32 bits".  This truncation is true
for tile since 3.4, and for the other relevant platforms (s390, powerpc,
sparc64, and mips) since 2.6.29.

As I said in my earlier email, the glibc piece is "belt and suspenders" for
when the kernel fix isn't present.  I'd argue it's pretty low overhead to
do so for the two architectures that already do it in glibc.  And it may be
that platforms other than tilegx and mipsn64 (i.e. s390, ppc, sparc) don't
do sign-extension for 32-bit "unsigned int".

-- 
Chris Metcalf, Tilera Corp.
http://www.tilera.com