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

[mlelstv%serpens.de@localhost (Michael van Elst)]

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

From: mlelstv%serpens.de@localhost (Michael van Elst)
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 08:02:43 -0000 (UTC)

 kre%munnari.OZ.AU@localhost (Robert Elz) writes:
 
 >   | If hz=50, then mstohz(10) returns 0.
 >   | This also means that timeouts are too short, rather than too long.
 
 > So simply switching to round up, without adjusting at least the first of
 > those (the +1's) wouldn't be a good idea (the ones using MAX() will work
 > either way).
 
 
 While there are places that work around the issue, there are others
 that do not. Auditing the code and cleaning up needs to happen with
 or without a change to mstohz().
 
 After that we should remove the assertion that waiting for 0 ticks is
 illegal. This case should be treated like the event had already occured.