Re: patch to fix set_itimer() behaviour in boundary cases

["Randy.Dunlap" <rddunlap@osdl.org>]

Matthias Lang wrote:
> Chris Wedgewood suggested handling this with a printk, to which Arjan
> van de Ven asked 
> 
>  > but why????
>  > 
>  > if someone wants the stuff rejected in a posix confirm way, he can do
>  > these tests easily in the syscall wrapper he needs anyway for this
>  > function.
> 
> For negative times and oversized usec values, that's easy. But the
> third problem was that setitimer() may silently truncate the time
> value. To deal with that, a wrapper would need to
> 
>   a) know that this silent truncation happens in the first place. 
>      The only way I know of finding that out is to read the kernel
>      source. (the man page doesn't say anything, and POSIX doesn't
>      mention any silent truncation either)
> 
> and
> 
>   b) Know that the particular value the truncation happens at is
>      dependent on HZ (and, presumably, know what HZ is on that
>      particular machine)
>  
> I found it surprising that the timer set by setitimer() could expire
> before the time passed to it---the manpage explicitly promises that
> will never happen. 
> 
> On many (most?) machines, the obvious symptoms of this truncation
> don't start appearing until after 248 days of uptime, so it's not the
> sort of problem which jumps out in testing. A printk() warning would
> have helped me. As would a warning in the manpage, e.g.:
> 
>    | BUGS
>    |
>    | Under Linux, timers will expire before the requested time if the
>    | requested time is larger than MAX_SEC_IN_JIFFIES, which is
>    | defined in include/linux/jiffies.h.
> 
> Where can I send manpage improvements?

aeb wrote on 2004-OCT-31:

Fortunately Michael Kerrisk has accepted to take over.
Send corrections and additions to mtk-manpages@gmx.net .

-- 
~Randy