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

[Matthias Lang]

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?

Matthias
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/