: DELAYTIMER_MAX is defined

Hello,

Playing around with the posix timers I've noticed that DELAYTIMER_MAX is not defined. This constant is specified in the POSIX specifications. It should contain the maximum possible value of overruns on a signal. It is also said that the overrun shouldn't overflow. cf
http://www.opengroup.org/onlinepubs/007904975/functions/timer_getoverrun.html

So here is a patch to add this constant and a check that the overrun variable never overflow. It's for 2.5.67 but should apply flawlessly to 2.5.69 too.
Actually one could wonder if the test on the overflow is really needed has an overrun reaching 2^31 seems very hard to happen. However the constant definition is not hurting anything and looks necessary for closer POSIX compliance.

Eric

------------------------------------------------------------------------

diff -ur linux-2.5.67-ia64-hrtcore/include/linux/limits.h linux-2.5.67-ia64-hrtimers/include/linux/limits.h

include/linux/limits.h +2 -0

@@ -17,6 +17,8 @@
 #define XATTR_SIZE_MAX 65536	/* size of an extended attribute value (64k) */
 #define XATTR_LIST_MAX 65536	/* size of extended attribute namelist (64k) */
 
+#define DELAYTIMER_MAX INT_MAX	/* # timer expiration overruns a POSIX.1b timer may have */
+
 #define RTSIG_MAX	  32
 
 #endif

diff -ur linux-2.5.67-ia64-hrtcore/include/linux/posix-timers.h linux-2.5.67-ia64-hrtimers/include/linux/posix-timers.h

include/linux/posix-timers.h +2 -1

@@ -25,6 +59,7 @@
 
 #define posix_bump_timer(timr) do { \
                         (timr)->it_timer.expires += (timr)->it_incr; \
-                        (timr)->it_overrun++;               \
+                        if ((timr)->it_overrun < DELAYTIMER_MAX)\
+                            (timr)->it_overrun++;               \
                        }while (0)
 #endif

Quoted 6 lines · Eric Piel

Playing around with the posix timers I've noticed that DELAYTIMER_MAX is not defined. This constant is specified in the POSIX specifications. It should contain the maximum possible value of overruns on a signal. It is also said that the overrun shouldn't overflow. cf
http://www.opengroup.org/onlinepubs/007904975/functions/timer_getoverrun.html

Quoted 3 lines

So here is a patch to add this constant and a check that the overrun variable never overflow. It's for 2.5.67 but should apply flawlessly to 2.5.69 too.

I think this is needed in glibc. I am not sure how that relates to kernel defines.

include/linux/posix-timers.h line 64

Quoted 6 lines

 #define posix_bump_timer(timr) do { \
                         (timr)->it_timer.expires += (timr)->it_incr; \

include/linux/posix-timers.h +2 -1

-                        (timr)->it_overrun++;               \
+                        if ((timr)->it_overrun < DELAYTIMER_MAX)\
+                            (timr)->it_overrun++;               \
                        }while (0)

Quoted 5 lines

Quoted 5 lines

Playing around with the posix timers I've noticed that DELAYTIMER_MAX is not defined. This constant is specified in the POSIX specifications. It should contain the maximum possible value of overruns on a signal. It is also said that the overrun shouldn't overflow. cf
http://www.opengroup.org/onlinepubs/007904975/functions/timer_getoverrun.html

This is not correct. The constant does not have to be defined. Like all the various *_MAX constants they only have to be defined if there is a fixed limit the implementation has. If there is none or it can only be defined dynamically at runtime the the macro must not be defined. Instead sysconf() can provide the value. But not even this is necessary. sysconf() can return -1.

Anyway, in this specific case the implementation should be protected against the ever so improbable overflow of the counter, yes. If you want a fixed value, fine. If you want to use ULONG_MAX (or whatever), good too. Whether we advertise this limit is another thing. Advertising it in the macro means it never can be changed.

Quoted 6 lines · Ulrich Drepper

This is not correct. The constant does not have to be defined. Like all the various *_MAX constants they only have to be defined if there is a fixed limit the implementation has. If there is none or it can only be defined dynamically at runtime the the macro must not be defined. Instead sysconf() can provide the value. But not even this is necessary. sysconf() can return -1.

Sorry, I wasn't aware about this POSIX rule, thank you for pointing out this. Knowing that it would obviously be better providing support of the constant _SC_DELAYTIMER_MAX for sysconf() and return a value.

This would imply there is now some job for glibc. However it's still
unclear for me how the glibc would know about wich value it should return while this question would be so easy to answer for the kernel! Also AFAIK, right now, only the NPTL supports the new syscalls for the
timers (and none supports the clocks syscalls). Does it mean a special
__sysconf() is necessary in the NPTL? Well, probably that's why you suggested -1 as a return value I guess :-)

Quoted 6 lines

Anyway, in this specific case the implementation should be protected against the ever so improbable overflow of the counter, yes. If you want a fixed value, fine. If you want to use ULONG_MAX (or whatever), good too. Whether we advertise this limit is another thing. Advertising it in the macro means it never can be changed.

You are right also here, of course with this point of view it's better not putting any constant.
So the patch could become something like that: ?

diff -ur linux-2.5.67-ia64-hrtcore/include/linux/posix-timers.h linux-2.5.67-ia64-hrtimers/include/linux/posix-timers.h

include/linux/posix-timers.h 2003-05-06 16:07:56.000000000 +0200 renamed from include/linux/posix-timers.h 2003-04-22 11:10:44.000000000 +0200 +2 -1

@@ -25,6 +59,7 @@
 
 #define posix_bump_timer(timr) do { \
                         (timr)->it_timer.expires += (timr)->it_incr; \
-                        (timr)->it_overrun++;               \
+                        if ((timr)->it_overrun < INT_MAX)\
+                            (timr)->it_overrun++;               \
                        }while (0)
 #endif

Eric

This, of course, also says that we should not only limit the value of overrun, but also do something different when it happens.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

george anzinger wrote:

Quoted 2 lines

This, of course, also says that we should not only limit the value of overrun, but also do something different when it happens.

That's legitimate and in this case we perhaps should publish this lower value since it can be limiting. Since real work is involved in having higher values this constitutes another possible DoS in the code and has to be resolved.

Andrew Morton suggested
an rlimit for that. Perhaps that is what should be used here also.

Seem reasonable?