Re: [PATCH] ioctl_list.2: BLKRASET/BLKRAGET take unsigned long

[Cyril Hrubis <chrubis-AlSwsSmVLrQ@public.gmane.org>]

Hi!
> >> I also wonder if it's OK to pass int value to ioctl() at all, the arg
> >> value seems to be unsigned long in the syscall definition in fs/ioctl.c
> >> and there does not seem to be any glibc magic around the syscall.
> 
> This shouldn't matter, if you pass an 'int' into a function that takes
> a 'long', it will be extended if necessary. The question is more about
> how it gets interpreted, and in this case it's done by assigning to

I guess that it may, since the ioctl() prototype is defined with ...

>From /usr/include/sys/ioctl.h:

...
extern int ioctl (int __fd, unsigned long int __request, ...) __THROW;
...

Looking at dissasembly we do:

4005bb:       89 c7                   mov    %eax,%edi
(%eax holds fd from open())

...

4005bb:       89 c7                   mov    %eax,%edi
4005bd:       ba 00 02 00 00          mov    $0x200,%edx
                                                    ^
						We do 32bit load here

4005c2:       be 62 12 00 00          mov    $0x1262,%esi
4005c7:       31 c0                   xor    %eax,%eax
4005c9:       e8 72 ff ff ff          callq  400540 <ioctl@plt>

The ioctl assembly just sets %eax and then syscall.

So as far as I can tell we depend here on a fact that upper part of $rdx
is zeroed. Not sure if that is guaranteed or not.

-- 
Cyril Hrubis
chrubis-AlSwsSmVLrQ@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html