svn commit: r215791 - stable/8/sys/netinet

[Bruce Evans]

On Wed, 24 Nov 2010, Gleb Smirnoff wrote:

> On Wed, Nov 24, 2010 at 06:11:53PM +1100, Bruce Evans wrote:
> B> > +++ stable/8/sys/netinet/if_ether.c	Wed Nov 24 05:37:12 2010	(r215791)
> B> > @@ -381,7 +381,7 @@ retry:
> B> > 		int canceled;
> B> >
> B> > 		LLE_ADDREF(la);
> B> > -		la->la_expire = time_second + V_arpt_down;
> B> > +		la->la_expire = time_second;
> B> > 		canceled = callout_reset(&la->la_timer, hz * V_arpt_down,
> B> > 		    arptimer, la);
> B> > 		if (canceled)
> B> >
> B>
> B> Isn't using non-monotic time for timeouts always wrong?
                      monotonic
>
> Sure it is wrong. I never payed attention to that fact that time_second
> could be non-monotic. Is it non-monotic? I failed to understand kern_tc
> code at first glance.

Real time (time_second) can go backwards (or jump forwards too much)
if someone steps the the clock.  In kern_tc.c, time_uptime is implemented
as a purely monotonic clock which goes forward by 1 (second) approximately
every 1 second of real-real-time, while time_second is misimplemented
as essentially (boottime.tv_sec + time_uptime), where boottime is
bogusly changed (although the actual boot time didn't change) if someone
steps the realtime clock to fix drift in it, including for POSIX leap
seconds and resumes.  (Suspends stop the monotonic clock, and on resume
only the real time clock is advanced by much (by bogusly setting boottime
forwards so that (boottime.tv_sec + time_uptime) gives the correct real
time.)

Using real time is actually correct for some timeouts, mainly for long
ones.  E.g., ones for the next day shouldn't be 8 hours late because the
system was suspended overnight.

Bruce