[LTP] [PATCH V3] syscalls/timer_settime01: Make sure the timer fires

[Yang Xu]

HI Cyril


> Hi!
>>>> When tesing timer_settime01 on 3.10.0-1136.el7.x86_64, this case fails
>>>> whether we use any type clock.
>>>>
>>>> timer_settime01.c:174: PASS: timer_settime(CLOCK_BOOTTIME) passed
>>>> timer_settime01.c:164: FAIL: timer_gettime(CLOCK_BOOTTIME_ALARM) reported
>>>> bad values (0: 678013000): SUCCESS (0)
>>>> timer_settime01.c:174: PASS: timer_settime(CLOCK_BOOTTIME_ALARM) passed
>>>> timer_settime01.c:164: FAIL: timer_gettime(CLOCK_REALTIME_ALARM) reported
>>>> bad values (0: 358240000): SUCCESS (0)
>>>> timer_settime01.c:174: PASS: timer_settime(CLOCK_REALTIME_ALARM) passed
>>>> timer_settime01.c:174: PASS: timer_settime(CLOCK_TAI) passed
>>>
>>> Can you share the complete test log? I am not sure if only the _ALARM
>>> cocks are failing or all. You are getting values in the order of
>>> 300-700 ms, while the max value can't be greater than 50 ms. So seems
>>> like a kernel issue to me. Over that, both _ALARM type clocks weren't
>>> supported before 3.11 and looks like your kernel version is 3.10.
>> Yes, only _ALARM fails. I  only find a kernel patch (commit
>> 11ffa9d6065f344  timerfd: Add alarm timers) introduced alarm clock types
>> for timefd in kernel 3.11 and  a kernel patch (commit 9a7adcf5c6dea63d
>> timers: Posix interface for alarm-timers)  in kernel 3.1. It seems my
>> kernel version has supported this two alarm clock, but not sure why this
>> case fails.
> 
> This is on RHEL kernel that has backported the _ALARM support right? So
> this may as well be case of badly bacported patch...
Just double check. My previous word may  make you feel confused.
On RHEL7 kernel, timer_* includes ALARM supports because kernel has 
upported it since 3.1 and timers_fd doesn't introduced ALARM 
support(REHL7 doesn't backport this patch). IMO, this case doesn't 
call/use timerfd_* function. We only need timer_*  ALARM suuport to run 
this case. so it doesn't need to backport ALARM support. Or, I miss some 
thing?
>