From nobody@FreeBSD.org  Sun Aug 29 21:57:38 2010
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id D0458106566B
	for <freebsd-gnats-submit@FreeBSD.org>; Sun, 29 Aug 2010 21:57:38 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21])
	by mx1.freebsd.org (Postfix) with ESMTP id 88BDE8FC0C
	for <freebsd-gnats-submit@FreeBSD.org>; Sun, 29 Aug 2010 21:57:38 +0000 (UTC)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.14.3/8.14.3) with ESMTP id o7TLvc7R084629
	for <freebsd-gnats-submit@FreeBSD.org>; Sun, 29 Aug 2010 21:57:38 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.14.3/8.14.3/Submit) id o7TLvcDT084628;
	Sun, 29 Aug 2010 21:57:38 GMT
	(envelope-from nobody)
Message-Id: <201008292157.o7TLvcDT084628@www.freebsd.org>
Date: Sun, 29 Aug 2010 21:57:38 GMT
From: Garrett Cooper <yaneurabeya@gmail.com>
To: freebsd-gnats-submit@FreeBSD.org
Subject: [patch] Account for reserved itimers which shouldn't count against _SC_TIMER_MAX
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         150095
>Category:       kern
>Synopsis:       [kernel] [patch] Account for reserved itimers which shouldn't count against _SC_TIMER_MAX
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    mav
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun Aug 29 22:00:04 UTC 2010
>Closed-Date:    
>Last-Modified:  Sun May 04 04:12:25 UTC 2014
>Originator:     Garrett Cooper
>Release:        9-CURRENT
>Organization:
Cisco Systems, Inc.
>Environment:
FreeBSD orangebox.local 9.0-CURRENT FreeBSD 9.0-CURRENT #10 r211794M: Sun Aug 29 21:21:29 UTC 2010     gcooper@orangebox.local:/usr/obj/usr/src/sys/ORANGEBOX  amd64
>Description:
Currently 3 reserve itimers are allocated purely for kernel use, but unfortunately this breaks the SUSv4 requirement which states:

{TIMER_MAX}
    Maximum number of timers per process supported by the implementation.
    Minimum Acceptable Value: {_POSIX_TIMER_MAX}

..

{_POSIX_TIMER_MAX}
    The per-process number of timers.
    Value: 32

Example (from testcases/open_posix_testsuite/conformance/behavior/timers in the LTP package):

$ ./1-1.run-test 
[29] timer_create() did not return success: Resource temporarily unavailable

After applying this patch, things function as expected:

$ ./1-1.run-test 
Test PASSED
>How-To-Repeat:
1. Grab LTP: the package needs to be July or later as I didn't apply many fixes to the branch until post that date -- this may require grabbing the source from git. See the sourceforge page for more info (http://sf.net/projects/ltp). Use ltp/ltp-dev instead of ltp/ltp in the directions, if ltp-dev.git still exists (I'm working on fixing that, because the directions on the webpage are incorrect).
2. Go to the open_posix_testsuite directory: cd $LTP_DIR/testcases/open_posix_testsuite
3. Generate the Makefiles: make generate-makefiles
4. Build the test: cd conformance/behavior/timers; make
5. Execute the test like: ./1-1.run-test
>Fix:


Patch attached with submission follows:

Index: sys/kern/kern_time.c
===================================================================
--- sys/kern/kern_time.c	(revision 211794)
+++ sys/kern/kern_time.c	(working copy)
@@ -356,9 +356,9 @@
 	struct timeval tv;
 	int error;
 
-	if (rqt->tv_nsec < 0 || rqt->tv_nsec >= 1000000000)
+	if (rqt->tv_sec < 0 || (rqt->tv_nsec < 0 || rqt->tv_nsec >= 1000000000))
 		return (EINVAL);
-	if (rqt->tv_sec < 0 || (rqt->tv_sec == 0 && rqt->tv_nsec == 0))
+	if (rqt->tv_sec == 0 && rqt->tv_nsec == 0)
 		return (0);
 	getnanouptime(&ts);
 	timespecadd(&ts, rqt);
@@ -995,7 +995,8 @@
 
 	PROC_LOCK(p);
 	if (preset_id != -1) {
-		KASSERT(preset_id >= 0 && preset_id < 3, ("invalid preset_id"));
+		KASSERT(preset_id >= 0 && preset_id < TIMER_RESERVED,
+		    ("invalid preset_id"));
 		id = preset_id;
 		if (p->p_itimers->its_timers[id] != NULL) {
 			PROC_UNLOCK(p);
@@ -1007,10 +1008,11 @@
 		 * Find a free timer slot, skipping those reserved
 		 * for setitimer().
 		 */
-		for (id = 3; id < TIMER_MAX; id++)
+		for (id = TIMER_RESERVED; id < (TIMER_RESERVED + TIMER_MAX);
+		    id++)
 			if (p->p_itimers->its_timers[id] == NULL)
 				break;
-		if (id == TIMER_MAX) {
+		if (id == (TIMER_RESERVED + TIMER_MAX)) {
 			PROC_UNLOCK(p);
 			error = EAGAIN;
 			goto out;
@@ -1144,7 +1146,7 @@
 		ovalp = NULL;
 
 	PROC_LOCK(p);
-	if (uap->timerid < 3 ||
+	if (uap->timerid < TIMER_RESERVED ||
 	    (it = itimer_find(p, uap->timerid)) == NULL) {
 		PROC_UNLOCK(p);
 		error = EINVAL;
@@ -1176,7 +1178,7 @@
 	int error;
 
 	PROC_LOCK(p);
-	if (uap->timerid < 3 ||
+	if (uap->timerid < TIMER_RESERVED ||
 	   (it = itimer_find(p, uap->timerid)) == NULL) {
 		PROC_UNLOCK(p);
 		error = EINVAL;
@@ -1206,7 +1208,7 @@
 	int error ;
 
 	PROC_LOCK(p);
-	if (uap->timerid < 3 ||
+	if (uap->timerid < TIMER_RESERVED ||
 	    (it = itimer_find(p, uap->timerid)) == NULL) {
 		PROC_UNLOCK(p);
 		error = EINVAL;
@@ -1483,7 +1485,7 @@
 		 * by new image.
 		 */
 		if (event == ITIMER_EV_EXEC)
-			i = 3;
+			i = TIMER_RESERVED;
 		else if (event == ITIMER_EV_EXIT)
 			i = 0;
 		else
Index: sys/sys/timers.h
===================================================================
--- sys/sys/timers.h	(revision 211794)
+++ sys/sys/timers.h	(working copy)
@@ -83,6 +83,8 @@
 
 #define	ITCF_ONWORKLIST	0x01
 
+/* Clocks reserved by setitimer */
+#define TIMER_RESERVED	3
 #define	TIMER_MAX	32
 
 #define	ITIMER_LOCK(it)		mtx_lock(&(it)->it_mtx)
@@ -94,7 +96,7 @@
 	struct itimerlist	its_virtual;
 	struct itimerlist	its_prof;
 	TAILQ_HEAD(, itimer)	its_worklist;
-	struct itimer		*its_timers[TIMER_MAX];
+	struct itimer		*its_timers[TIMER_RESERVED + TIMER_MAX];
 };
 
 struct	kclock {


>Release-Note:
>Audit-Trail:

From: Garrett Cooper <yaneurabeya@gmail.com>
To: bug-followup@FreeBSD.org, gcooper@FreeBSD.org
Cc:  
Subject: Re: kern/150095: [patch] Account for reserved itimers which shouldn't
 count against _SC_TIMER_MAX
Date: Sun, 29 Aug 2010 15:17:44 -0700

 --001636c5b05f914ff5048efdb74b
 Content-Type: text/plain; charset=ISO-8859-1
 
     Sorry... some noise from nanosleep was in the last patch (another
 bug I filed -- kern/149980). This patch only deals with the items I
 described.
 Thanks,
 -Garrett
 
 --001636c5b05f914ff5048efdb74b
 Content-Type: text/plain; charset=US-ASCII; name="account-for-reserved-itimers.diff.txt"
 Content-Disposition: attachment; 
 	filename="account-for-reserved-itimers.diff.txt"
 Content-Transfer-Encoding: base64
 X-Attachment-Id: f_gdggn4j40
 
 SW5kZXg6IHN5cy9rZXJuL2tlcm5fdGltZS5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09
 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9rZXJuL2tlcm5f
 dGltZS5jCShyZXZpc2lvbiAyMTE3OTQpCisrKyBzeXMva2Vybi9rZXJuX3RpbWUuYwkod29ya2lu
 ZyBjb3B5KQpAQCAtOTk1LDcgKzk5NSw4IEBACiAKIAlQUk9DX0xPQ0socCk7CiAJaWYgKHByZXNl
 dF9pZCAhPSAtMSkgewotCQlLQVNTRVJUKHByZXNldF9pZCA+PSAwICYmIHByZXNldF9pZCA8IDMs
 ICgiaW52YWxpZCBwcmVzZXRfaWQiKSk7CisJCUtBU1NFUlQocHJlc2V0X2lkID49IDAgJiYgcHJl
 c2V0X2lkIDwgVElNRVJfUkVTRVJWRUQsCisJCSAgICAoImludmFsaWQgcHJlc2V0X2lkIikpOwog
 CQlpZCA9IHByZXNldF9pZDsKIAkJaWYgKHAtPnBfaXRpbWVycy0+aXRzX3RpbWVyc1tpZF0gIT0g
 TlVMTCkgewogCQkJUFJPQ19VTkxPQ0socCk7CkBAIC0xMDA3LDEwICsxMDA4LDExIEBACiAJCSAq
 IEZpbmQgYSBmcmVlIHRpbWVyIHNsb3QsIHNraXBwaW5nIHRob3NlIHJlc2VydmVkCiAJCSAqIGZv
 ciBzZXRpdGltZXIoKS4KIAkJICovCi0JCWZvciAoaWQgPSAzOyBpZCA8IFRJTUVSX01BWDsgaWQr
 KykKKwkJZm9yIChpZCA9IFRJTUVSX1JFU0VSVkVEOyBpZCA8IChUSU1FUl9SRVNFUlZFRCArIFRJ
 TUVSX01BWCk7CisJCSAgICBpZCsrKQogCQkJaWYgKHAtPnBfaXRpbWVycy0+aXRzX3RpbWVyc1tp
 ZF0gPT0gTlVMTCkKIAkJCQlicmVhazsKLQkJaWYgKGlkID09IFRJTUVSX01BWCkgeworCQlpZiAo
 aWQgPT0gKFRJTUVSX1JFU0VSVkVEICsgVElNRVJfTUFYKSkgewogCQkJUFJPQ19VTkxPQ0socCk7
 CiAJCQllcnJvciA9IEVBR0FJTjsKIAkJCWdvdG8gb3V0OwpAQCAtMTE0NCw3ICsxMTQ2LDcgQEAK
 IAkJb3ZhbHAgPSBOVUxMOwogCiAJUFJPQ19MT0NLKHApOwotCWlmICh1YXAtPnRpbWVyaWQgPCAz
 IHx8CisJaWYgKHVhcC0+dGltZXJpZCA8IFRJTUVSX1JFU0VSVkVEIHx8CiAJICAgIChpdCA9IGl0
 aW1lcl9maW5kKHAsIHVhcC0+dGltZXJpZCkpID09IE5VTEwpIHsKIAkJUFJPQ19VTkxPQ0socCk7
 CiAJCWVycm9yID0gRUlOVkFMOwpAQCAtMTE3Niw3ICsxMTc4LDcgQEAKIAlpbnQgZXJyb3I7CiAK
 IAlQUk9DX0xPQ0socCk7Ci0JaWYgKHVhcC0+dGltZXJpZCA8IDMgfHwKKwlpZiAodWFwLT50aW1l
 cmlkIDwgVElNRVJfUkVTRVJWRUQgfHwKIAkgICAoaXQgPSBpdGltZXJfZmluZChwLCB1YXAtPnRp
 bWVyaWQpKSA9PSBOVUxMKSB7CiAJCVBST0NfVU5MT0NLKHApOwogCQllcnJvciA9IEVJTlZBTDsK
 QEAgLTEyMDYsNyArMTIwOCw3IEBACiAJaW50IGVycm9yIDsKIAogCVBST0NfTE9DSyhwKTsKLQlp
 ZiAodWFwLT50aW1lcmlkIDwgMyB8fAorCWlmICh1YXAtPnRpbWVyaWQgPCBUSU1FUl9SRVNFUlZF
 RCB8fAogCSAgICAoaXQgPSBpdGltZXJfZmluZChwLCB1YXAtPnRpbWVyaWQpKSA9PSBOVUxMKSB7
 CiAJCVBST0NfVU5MT0NLKHApOwogCQllcnJvciA9IEVJTlZBTDsKQEAgLTE0ODMsNyArMTQ4NSw3
 IEBACiAJCSAqIGJ5IG5ldyBpbWFnZS4KIAkJICovCiAJCWlmIChldmVudCA9PSBJVElNRVJfRVZf
 RVhFQykKLQkJCWkgPSAzOworCQkJaSA9IFRJTUVSX1JFU0VSVkVEOwogCQllbHNlIGlmIChldmVu
 dCA9PSBJVElNRVJfRVZfRVhJVCkKIAkJCWkgPSAwOwogCQllbHNlCkluZGV4OiBzeXMvc3lzL3Rp
 bWVycy5oCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
 PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9zeXMvdGltZXJzLmgJKHJldmlzaW9uIDIxMTc5NCkK
 KysrIHN5cy9zeXMvdGltZXJzLmgJKHdvcmtpbmcgY29weSkKQEAgLTgzLDYgKzgzLDggQEAKIAog
 I2RlZmluZQlJVENGX09OV09SS0xJU1QJMHgwMQogCisvKiBDbG9ja3MgcmVzZXJ2ZWQgYnkgc2V0
 aXRpbWVyICovCisjZGVmaW5lIFRJTUVSX1JFU0VSVkVECTMKICNkZWZpbmUJVElNRVJfTUFYCTMy
 CiAKICNkZWZpbmUJSVRJTUVSX0xPQ0soaXQpCQltdHhfbG9jaygmKGl0KS0+aXRfbXR4KQpAQCAt
 OTQsNyArOTYsNyBAQAogCXN0cnVjdCBpdGltZXJsaXN0CWl0c192aXJ0dWFsOwogCXN0cnVjdCBp
 dGltZXJsaXN0CWl0c19wcm9mOwogCVRBSUxRX0hFQUQoLCBpdGltZXIpCWl0c193b3JrbGlzdDsK
 LQlzdHJ1Y3QgaXRpbWVyCQkqaXRzX3RpbWVyc1tUSU1FUl9NQVhdOworCXN0cnVjdCBpdGltZXIJ
 CSppdHNfdGltZXJzW1RJTUVSX1JFU0VSVkVEICsgVElNRVJfTUFYXTsKIH07CiAKIHN0cnVjdAlr
 Y2xvY2sgewo=
 --001636c5b05f914ff5048efdb74b--
Responsible-Changed-From-To: freebsd-bugs->mav 
Responsible-Changed-By: arundel 
Responsible-Changed-When: Sun Sep 5 19:48:04 UTC 2010 
Responsible-Changed-Why:  
If I remember correctly Alexander Motin is working on timers. He might know how 
to handle this PR. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=150095 

From: Alexander Motin <mav@FreeBSD.org>
To: bug-followup@FreeBSD.org, gcooper@FreeBSD.org
Cc: arundel@freebsd.org, davidxu@freebsd.org
Subject: Re: kern/150095: [patch] Account for reserved itimers which shouldn't
 count against _SC_TIMER_MAX
Date: Mon, 06 Sep 2010 11:35:18 +0300

 Hi.
 
 Sorry, but this is not my area of knowledge yet. I am working on kernel
 time event producing, while this is consuming, half way to user-level.
 
 Still few comments from quick review:
  - patch seems slightly incomplete. At least in itimers_alloc() loop
 condition need to be changed.
  - To reduce chance of alike mistakes I would implement that patch in
 opposite way, by defining TIMER_MAX as (32 + TIMER_RESERVED), but
 reporting to user-level as TIMER_MAX - TIMER_RESERVED.
  - I have looked on setitimer() implementation referenced here and found
 no any interaction with timer_create() API and TIMER_MAX. There is
 indeed many loose ends which make me thing there was or intended to be
 something, but I haven't found it. Have I missed something?
  - this code was written by David Xu. I would asked him.
 
 -- 
 Alexander Motin

From: David Xu <davidxu@freebsd.org>
To: Alexander Motin <mav@freebsd.org>
Cc: bug-followup@freebsd.org, gcooper@freebsd.org, arundel@freebsd.org
Subject: Re: kern/150095: [patch] Account for reserved itimers which shouldn't
 count against _SC_TIMER_MAX
Date: Mon, 06 Sep 2010 17:48:03 +0000

 Alexander Motin wrote:
 > Hi.
 > 
 > Sorry, but this is not my area of knowledge yet. I am working on kernel
 > time event producing, while this is consuming, half way to user-level.
 > 
 > Still few comments from quick review:
 >  - patch seems slightly incomplete. At least in itimers_alloc() loop
 > condition need to be changed.
 >  - To reduce chance of alike mistakes I would implement that patch in
 > opposite way, by defining TIMER_MAX as (32 + TIMER_RESERVED), but
 > reporting to user-level as TIMER_MAX - TIMER_RESERVED.
 >  - I have looked on setitimer() implementation referenced here and found
 > no any interaction with timer_create() API and TIMER_MAX. There is
 > indeed many loose ends which make me thing there was or intended to be
 > something, but I haven't found it. Have I missed something?
 >  - this code was written by David Xu. I would asked him.
 > 
 
 Yes, the code was written by me long time ago, my original intention
 was to not only implement timer_create() but also merge existing
 setitimer() code into unique module, but I had never done it
 because lack of time, so three slots were reserved for setitimer.
 I can see that there is inconsistent between TIMER_MAX and maximum
 timers user can create, your both methods will work.
 
 Thanks,
 David Xu
 
 
 

From: Garrett Cooper <yaneurabeya@gmail.com>
To: Alexander Motin <mav@freebsd.org>
Cc: bug-followup@freebsd.org, arundel@freebsd.org, davidxu@freebsd.org
Subject: Re: kern/150095: [patch] Account for reserved itimers which shouldn't
 count against _SC_TIMER_MAX
Date: Wed, 8 Sep 2010 00:34:21 -0700

 2010/9/6 Alexander Motin <mav@freebsd.org>:
 > Hi.
 >
 > Sorry, but this is not my area of knowledge yet. I am working on kernel
 > time event producing, while this is consuming, half way to user-level.
 >
 > Still few comments from quick review:
 > =A0- patch seems slightly incomplete. At least in itimers_alloc() loop
 > condition need to be changed.
 
 Good catch. I'll need to look around for more potential issues with TIMER_M=
 AX.
 
 > =A0- To reduce chance of alike mistakes I would implement that patch in
 > opposite way, by defining TIMER_MAX as (32 + TIMER_RESERVED), but
 > reporting to user-level as TIMER_MAX - TIMER_RESERVED.
 
 Why? A timer ID is a timer ID... Linux reports whacky values for timer
 IDs, and while we report fairly sensical ones (0-TIMER_MAX), people
 need to check the timer ID value, and don't assume that the return
 value is correct. There is one case that I can think of that you're
 guarding against (poorly written code, where timer ID =3D=3D 0, someone
 whacks a kernel timer by accident as root, and things don't go so
 well). That's one thing that I suppose the random timer ID values in
 Linux protect against (they aren't really deterministic from what I
 saw, so people either get things spot on by a stroke of luck, or their
 app goes south with a segfault, etc).
 
 Thanks,
 -Garrett

From: Garrett Cooper <yaneurabeya@gmail.com>
To: David Xu <davidxu@freebsd.org>
Cc: Alexander Motin <mav@freebsd.org>, bug-followup@freebsd.org, arundel@freebsd.org
Subject: Re: kern/150095: [patch] Account for reserved itimers which shouldn't
 count against _SC_TIMER_MAX
Date: Wed, 8 Sep 2010 00:35:48 -0700

 2010/9/6 David Xu <davidxu@freebsd.org>:
 > Alexander Motin wrote:
 >>
 >> Hi.
 >>
 >> Sorry, but this is not my area of knowledge yet. I am working on kernel
 >> time event producing, while this is consuming, half way to user-level.
 >>
 >> Still few comments from quick review:
 >> =A0- patch seems slightly incomplete. At least in itimers_alloc() loop
 >> condition need to be changed.
 >> =A0- To reduce chance of alike mistakes I would implement that patch in
 >> opposite way, by defining TIMER_MAX as (32 + TIMER_RESERVED), but
 >> reporting to user-level as TIMER_MAX - TIMER_RESERVED.
 >> =A0- I have looked on setitimer() implementation referenced here and fou=
 nd
 >> no any interaction with timer_create() API and TIMER_MAX. There is
 >> indeed many loose ends which make me thing there was or intended to be
 >> something, but I haven't found it. Have I missed something?
 >> =A0- this code was written by David Xu. I would asked him.
 >>
 >
 > Yes, the code was written by me long time ago, my original intention
 > was to not only implement timer_create() but also merge existing
 > setitimer() code into unique module, but I had never done it
 > because lack of time, so three slots were reserved for setitimer.
 > I can see that there is inconsistent between TIMER_MAX and maximum
 > timers user can create, your both methods will work.
 
     Understood. Are there any other spots in the code that we need to
 be aware of in this particular area which are incomplete (I've seen
 that you've done a fair amount of work in libc/compat43 and libthr in
 the signal handling sections as well)?
 Thanks,
 -Garrett

From: Alexander Motin <mav@FreeBSD.org>
To: Garrett Cooper <yaneurabeya@gmail.com>
Cc: bug-followup@freebsd.org, arundel@freebsd.org, davidxu@freebsd.org
Subject: Re: kern/150095: [patch] Account for reserved itimers which shouldn't
 count against _SC_TIMER_MAX
Date: Wed, 08 Sep 2010 10:44:06 +0300

 Garrett Cooper wrote:
 > 2010/9/6 Alexander Motin <mav@freebsd.org>:
 >> Sorry, but this is not my area of knowledge yet. I am working on kernel
 >> time event producing, while this is consuming, half way to user-level.
 >>
 >> Still few comments from quick review:
 >>  - patch seems slightly incomplete. At least in itimers_alloc() loop
 >> condition need to be changed.
 > 
 > Good catch. I'll need to look around for more potential issues with TIMER_MAX.
 > 
 >>  - To reduce chance of alike mistakes I would implement that patch in
 >> opposite way, by defining TIMER_MAX as (32 + TIMER_RESERVED), but
 >> reporting to user-level as TIMER_MAX - TIMER_RESERVED.
 > 
 > Why? A timer ID is a timer ID... Linux reports whacky values for timer
 > IDs, and while we report fairly sensical ones (0-TIMER_MAX), people
 > need to check the timer ID value, and don't assume that the return
 > value is correct. There is one case that I can think of that you're
 > guarding against (poorly written code, where timer ID == 0, someone
 > whacks a kernel timer by accident as root, and things don't go so
 > well). That's one thing that I suppose the random timer ID values in
 > Linux protect against (they aren't really deterministic from what I
 > saw, so people either get things spot on by a stroke of luck, or their
 > app goes south with a segfault, etc).
 
 While I indeed worried about some possible ID constraints in user-level,
 I was mostly speaking about kernel code clearness. My point was
 depending on assumption that from kernel side all usual and reserved
 timers handled same way and so it would be nice to have dedicated
 constant defining their count instead of use addition every time, having
 a constant chance of mistake. This point is surely not mandatory and may
 be ungrounded, but I would at least added one more constant describing
 full number of timers, including reserved. Also, as soon as reserved
 timers are never really used, we could probably choose which one to
 reserve - first or last 3, if it could make code more clear.
 
 -- 
 Alexander Motin

From: David Xu <davidxu@freebsd.org>
To: Garrett Cooper <yaneurabeya@gmail.com>
Cc: Alexander Motin <mav@freebsd.org>, bug-followup@freebsd.org,
        arundel@freebsd.org
Subject: Re: kern/150095: [patch] Account for reserved itimers which shouldn't
 count against _SC_TIMER_MAX
Date: Wed, 08 Sep 2010 16:49:56 +0000

 Garrett Cooper wrote:
 > 2010/9/6 David Xu <davidxu@freebsd.org>:
 >> Alexander Motin wrote:
 >>> Hi.
 >>>
 >>> Sorry, but this is not my area of knowledge yet. I am working on kernel
 >>> time event producing, while this is consuming, half way to user-level.
 >>>
 >>> Still few comments from quick review:
 >>>  - patch seems slightly incomplete. At least in itimers_alloc() loop
 >>> condition need to be changed.
 >>>  - To reduce chance of alike mistakes I would implement that patch in
 >>> opposite way, by defining TIMER_MAX as (32 + TIMER_RESERVED), but
 >>> reporting to user-level as TIMER_MAX - TIMER_RESERVED.
 >>>  - I have looked on setitimer() implementation referenced here and found
 >>> no any interaction with timer_create() API and TIMER_MAX. There is
 >>> indeed many loose ends which make me thing there was or intended to be
 >>> something, but I haven't found it. Have I missed something?
 >>>  - this code was written by David Xu. I would asked him.
 >>>
 >> Yes, the code was written by me long time ago, my original intention
 >> was to not only implement timer_create() but also merge existing
 >> setitimer() code into unique module, but I had never done it
 >> because lack of time, so three slots were reserved for setitimer.
 >> I can see that there is inconsistent between TIMER_MAX and maximum
 >> timers user can create, your both methods will work.
 > 
 >     Understood. Are there any other spots in the code that we need to
 > be aware of in this particular area which are incomplete (I've seen
 > that you've done a fair amount of work in libc/compat43 and libthr in
 > the signal handling sections as well)?
 > Thanks,
 > -Garrett
 > 
 
 Note that there is a userland library called librt which wraps around
 the kernel system calls, the reason is specification requires
 SEGEV_THREAD notification type, and struct sigevent
 contains pthread_attr_t pointer which is used for creating
 service thread, the pthread is unknown to kernel, so the library
 is created, translating SIGEV_THREAD_ID into SIGEV_THREAD notification.
 the timer id is not directly accessed by user code, instead user code
 uses timer_t which is a pointer of structure __timer, however the timer
 id is saved in the structure.
 
 Regards,
 David Xu
 
>Unformatted:
