svn commit: r296543 - head/sys/compat/linux

[Bruce Evans]

On Sun, 20 Mar 2016, Chagin Dmitry wrote:

> On Wed, Mar 09, 2016 at 07:16:27PM +1100, Bruce Evans wrote:
>> On Tue, 8 Mar 2016, Dmitry Chagin wrote:
>>
>>> Log:
>>>  Put a commit message from r296502 about Linux alarm() system call
>>>  behaviour to the source.
>>> ...
>>> Modified: head/sys/compat/linux/linux_misc.c
>>> ==============================================================================
>>> --- head/sys/compat/linux/linux_misc.c	Tue Mar  8 19:08:55 2016	(r296542)
>>> +++ head/sys/compat/linux/linux_misc.c	Tue Mar  8 19:20:57 2016	(r296543)
>>> @@ -206,6 +206,11 @@ linux_alarm(struct thread *td, struct li
>>> 	it.it_value.tv_usec = 0;
>>> 	it.it_interval.tv_sec = 0;
>>> 	it.it_interval.tv_usec = 0;
>>> +	/*
>>> +	 * According to POSIX and Linux implementation
>>> +	 * the alarm() system call is always successfull.
>>> +	 * Ignore errors and return 0 as a Linux do.
>>> +	 */
>>
>> Why does this need a comment referring to external sources?  FreeBSD's
>> own man page also says that there is no error return for alarm(3).
>> However, the man page and the implementation are quite broken.  The
>> implementation in libc does have an error return, but this is
>> undocumented.  The documentation says that that the maximum number of
>> seconds is 100000000 (100 million), but doesn't say what happens when
>> this limit is exceeded.  The implementation of this is broken too.
>> ...
> Thank you very match, Bruce for you pont! Should I correct setitimer/alarm man pages
> about maximum seconds?

Yes, the current limit seems to work well enough, since it adds at most
1 copy of INT32_MAX / 2 to the current uptime, and the current uptime is
limited to well below INT32_MAX / 2 in practice.

This is related to the brokenness of timeouts across suspend/resume.
alarm(86400) doesn't work to get an alarm every day, because timeouts
are relative to the uptime, and the uptime doesn't count time across
suspend/resume.  Most FreeBSD time functions are broken by this.

I noticed some neary bugs while checking this:
- realitexpire() has a rotted comment about its previous use of tvtohz()
- the loop to add it_interval in realitexpire() has some denial of
   service potential.  In FreeBSD-9, the overflow bug exists and can be
   used to create a negative expiry time, but in my tests the loop was not
   reached in that case.  If it were reached, then it would iterate about
   2**22 times with 64-bit time_t.
- itimerfix() has a rotted comment about its minimal value.  (I think
   POSIX doesn't allow rewriting the timeouts like that.  The timeouts
   should be const.  If rewriting them is permitted, then we could "fix"
   large times in the same way.)
- POSIX realtimers still use code similar to the old itimer code.  It
   has no bounds checks but needs them more since it supports absolute
   times and all clock ids.

Bruce