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
_______________________________________________
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
