From owner-svn-src-all@freebsd.org Sun Mar 20 17:52:12 2016 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8D3BCAD7B41; Sun, 20 Mar 2016 17:52:12 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail104.syd.optusnet.com.au (mail104.syd.optusnet.com.au [211.29.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id 580091D86; Sun, 20 Mar 2016 17:52:12 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c110-21-41-193.carlnfd1.nsw.optusnet.com.au (c110-21-41-193.carlnfd1.nsw.optusnet.com.au [110.21.41.193]) by mail104.syd.optusnet.com.au (Postfix) with ESMTPS id 1B90842404F; Mon, 21 Mar 2016 04:52:04 +1100 (AEDT) Date: Mon, 21 Mar 2016 04:52:03 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Chagin Dmitry cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r296543 - head/sys/compat/linux In-Reply-To: <20160320132637.GA88466@chd.heemeyer.club> Message-ID: <20160321003223.T2314@besplex.bde.org> References: <201603081920.u28JKvbM088851@repo.freebsd.org> <20160309160342.P1249@besplex.bde.org> <20160320132637.GA88466@chd.heemeyer.club> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=c+ZWOkJl c=1 sm=1 tr=0 a=73JWPhLeruqQCjN69UNZtQ==:117 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=kj9zAlcOel0A:10 a=0A-rwh1xptyzP0wGFi4A:9 a=QvDe-Mn7VEfrFuiQ:21 a=Gvi1W6LLpHJzkWJ-:21 a=CjuIK1q_8ugA:10 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Mar 2016 17:52:12 -0000 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