On Wed, May 26, 2021 at 05:35:53PM +1000, matthew green wrote:
> Manuel Bouyer writes:
> > On Tue, May 25, 2021 at 10:46:04PM -0000, Michael van Elst wrote:
> > > bou...@antioche.eu.org (Manuel Bouyer) writes:
> > >
> > > >Another issue could be mstohz() called with a delay too short;
> > > >mstohz() will round it up to 1 tick.
> > >
> > >
> > > # define mstohz(ms) ((unsigned int)((ms + 0ul) * hz / 1000ul))
> > >
> > > If mstohz() would round up to full ticks, it could actually avoid
> > > some pitfalls. But it doesn't.
> >
> > indeed. But in this case the problem will show up with smaller hz, not
> > larger. So I think we can rule out this case.
>
> it's hztoms() that is the problem here.
>
> # define hztoms(t) ((unsigned int)(((t) + 0ul) * 1000ul / hz))
>
> ah... this is the new one. the old one was:
>
> #define hztoms(t) \
> (__predict_false((t) >= 0x20000) ? \
> ((t +0u) / hz) * 1000u : \
> ((t +0u) * 1000u) / hz)
>
> looks like christos fixed it in 2019.
I'm not sure how christos's change could be a fix. I introduced hztoms()
and mstohz() to avoid interger overflow for large values, and it looks like
christos reintroduced it for 32bits platforms :(
--
Manuel Bouyer <bou...@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--
