Re: [LTP] [RFC] Timer related syscalls for LTP test

[Subrata Modak <subrata@linux.vnet.ibm.com>]

On Thu, 2010-05-27 at 16:40 +0530, Suzuki Poulose wrote: 
> Hi,
> 
> I have found a problem with the timer related syscall tests.
> 
> The following syscall tests, uses the direct syscall interface to the 
> kernel for testing the interface, instead of using the GLIBC interface.
> 
> testcases/kernel/syscalls
> 	\_ timer_getoverrun/
> 	\_ timer_gettime/
> 
> testcases/kernel/timers
> 	\_ timer_create/
> 	\_ timer_delete/
> 	\_ timer_settime/
> 
> So they use :
> 	syscall(__NR_timer_XXXX, args )
> for directly using the kernel syscall interface than using the
> 
> 	timer_xxxxx(args)
> 
> provided by the GLIBC. This is completely fine.
> 
> But however there is a mismatch in the "timer_t" type defined by the 
> Linux kernel and the GNU Libc.
> 
> Linux kernel defines it as an int for all architectures.
> 
> include/linux/types.h :
> 
> typedef __kernel_timer_t timer_t;
> 
> arch/powerpc/include/asm/posix_types.h :
> typedef int __kernel_timer_t;
> 
> 
> Now, the glibc provides a wrapper to the timer related system calls. 
> While providing the wrapper, Glibc stores some internal data associated 
> with the timer. So it defines the "timer_t" as a pointer (void*) as below:
> 
> /usr/include/time.h :
> 
> /* Timer ID returned by `timer_create'.  */
> typedef __timer_t timer_t;
> 
> 
> in /usr/include/bits/types.h :
> 
> /* Timer ID returned by `timer_create'.  */
> __STD_TYPE __TIMER_T_TYPE __timer_t;
> 
> in /usr/include/bits/typesizes.h
> 
> #define __TIMER_T_TYPE          void *
> 
> 
> So that leads to the definiton of timer_t as void* by glibc. And this 
> cannot be changed. But the glibc uses the "proper" typed argument for 
> the syscalls it issues by defining a kernel_timer_t.
> 
> On 32bit machines the difference is not noticed, since both the timer_t 
> in userspace and the kernel space are of the same size. But on 64bit 
> machines this is different.
> 
> Userspace has a width of 64bit and the kernel has 32bit width. Now, when 
> we pass the pointer to timer_t to the kernel, things get complicated and 
> on Big endian machines, ppc64, s390x, this leads to a problem. As the 
> value kept is not available when we try to dereference it as a 32bit and 
> this leads to undesired results like below:
> 
> timer_getoverrun01    1  TFAIL  :  Block 1: test 0 FAILED... errno = 22 
> :Invalid argument
> 
> 
> strace shows :
> 
> 
> 13017 timer_create(CLOCK_REALTIME, {(nil), SIGALRM, SIGEV_SIGNAL, 
> {...}},{0x26e80}) = 0
> 13017 fstat(1, {st_dev=makedev(0, 11), st_ino=3, st_mode=S_IFCHR|0620,
> st_nlink=1, st_uid=0, st_gid=5, st_blksize=1024, st_blocks=0, 
> st_rdev=makedev(136, 0), 
> st_atime=2010/05/17-15:48:40,st_mtime=2010/05/17-15:48:40, 
> st_ctime=2010/05/17-13:15:48}) = 0
> 13017 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 
> -1, 0)= 0x20000028000
> 13017 write(1, "timer_getoverrun01    0  TINFO  "..., 66) = 66
> 13017 timer_getoverrun(0x26e80)         = -1 EINVAL (Invalid argument)
> 
> 
> So the conclusion is that, if we are using the System calls directly, we 
> should use the argument which is compatible with the kernel. We simply 
> *cannot* use the glibc definition and the kernel API directly.
> 
> I have a patch attached below that fixes this issue.

Thanks Suzie.

> 
> One more comment regarding the placement of timer_gettime and 
> timer_getoverrun syscall tests. I strongly believe they could be moved 
> to testcases/kernel/timers/ directory where the rest of the timer 
> related syscall tests are placed. If that change is made, we can use the 
> definition added in common_timers.h (in the patch) for those tests too, 
> instead of defining in each of the tests.

Sure, you can move them accordingly in the next patch :-)

Regards--
Subrata

> 
> 
> Thanks
> 
> Suzuki
> 
> 
> 
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> 
> _______________________________________________
> Ltp-list mailing list
> Ltp-list@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ltp-list


------------------------------------------------------------------------------

_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list