(forgive this fugly editor ;) Bruce Evans wrote: > On Thu, 6 May 2004, David Schultz wrote: > > > On Thu, May 06, 2004, P.D. Seniura wrote: > > > > > > > > It seems this bug happens when the HZ value goes below 16 > > > > > (either by compiling 'options HZ=' in kernel or setting > > > > > sysctl 'kern.hz=' in /boot/loader.conf). The computed > > > > > 'ticks' value becomes too large for 2-byte int producing > > > > > crazy overflowed numbers elsewhere. > > > > > > > > 16 is pretty low.. > > > > Then again it would be nice if it warned you or something similar when you > > > > tried it :) > > Nah, INT_MIN would be low. Values between INT_MIN and -1 might cause > even more interesting behaviour. The value of 0 would cause the not so > interesting behaviour of a panic for division by 0 in init_param1() if > not earlier. Nonexistent bounds checking for hz is just one of thousands > of cases of nonexistent bounds checking for tunables and sysctls. The > kernel trusts the (privileged) user not to set values that don't work. > > WHere is the 2-byte int that overflows? The kernel mostly uses > "int ticks = 1000000 / hz". It assumes at least 32-bit ints or that hz > 2. > This will work until hz becomes larger tha 1000000 or not nearly a divisor > of 1000000. That division is precisely what showed me where the overflow may lay. 1000000 / 16 = 62500 1000000 / 15 = 66666 (int fraction cut off) 66666 > 0xffff (2-byte int) 66666 & 0xffff = 1130 (base 10) 66666 & 0xffff0000 = 0x00010000 (leaks into another field?) Something is causing human clock timers to go crazy. ;) No biggee, just something I noticed. If I wanted "maximum oompf", I'd run single-user mode. ;) (hmmm there's that "mark of the beast" magic number and then some... ;) -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htmReceived on Fri May 07 2004 - 04:50:26 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:53 UTC