Re: kern/57718: mstohz rounds down, not up, which leads to surprising bugs when it rounds to zero

[Robert Elz <kre%munnari.OZ.AU@localhost>]

The following reply was made to PR kern/57718; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: kern/57718: mstohz rounds down, not up, which leads to surprising bugs when it rounds to zero
Date: Wed, 22 Nov 2023 17:39:52 +0700

     Date:        Wed, 22 Nov 2023 10:00:03 +0000 (UTC)
     From:        mlelstv%serpens.de@localhost (Michael van Elst)
     Message-ID:  <20231122100003.423D01A9239%mollari.NetBSD.org@localhost>
 
   |  If you round up, you will get 0 when you pass 0.
 
 Sure, and I should have been clearer - there are some cases where the
 parameter can be zero, but in all I have seen so far (just a couple)
 the code handles that specially, and tends to not even call mstohz()
 (or issue any kind of kpause/callout/...) in that case.
 
 The "expects not to get zero" was in the case the parameter was not 0,
 even if the code is clearly attempting to get the minimum delay it
 believes is possible (mstohz(10) is quite common).
 
 I see (but have not thoroughly examined yet) some mstohz(1) calls - where
 a 0 result is clearly not wanted (a KASSERT would fire if that happened)
 and so which can only possibly work if hz>=1000 (these are in arch/sparc64
 so that assumption is probably true by default, but hz is a kernel config
 setting, and even on sparc64 someone could set hz to < 1000).
 
   |  Consistently waiting for "at least" the time (aka rounding up) is
   |  consistent with the world,
 
 Yes, for timeouts, and user code, but for device polling one cannot
 usually just wait "anything longer than  ..." or events might be lost.
 Typically polling would prefer to simply busy loop, but that is "unkind"
 to the rest of the system, so tends to pause, but is almost always going
 to prefer a smaller wait to a longer one.
 
 kre
 
 ps: the 32 bit version of hztoms() in sys/param.h looks to be potentially
 broken, if HZ is set higher than 131072 (yes, I know, extremely unlikely
 on any 32 bit processor) it will fail, and will be returning inaccurate
 results for large hz values for HZ settings down to about 10000 (still
 unlikely on such a processor).    There probably should be some mention
 in the doc somewhere (config(8)?) that the HZ value needs to be sane on
 32 bit processors, along with some indication what sane means.