Re: PSA: If you run -current, beware!

On Thursday, February 05, 2015 11:00:46 AM Peter Wemm wrote:
> On Thursday, February 05, 2015 10:48:54 AM John Baldwin wrote:
> > On Thursday, February 05, 2015 04:22:23 PM Luigi Rizzo wrote:
> > > On Thu, Feb 05, 2015 at 08:21:45AM -0500, John Baldwin wrote:
> > > > On Thursday, February 05, 2015 08:48:33 AM Luigi Rizzo wrote:
> > > ...
> > > 
> > > > > > > It is fixed (in the proper meaning of the word, not like worked
> > > > > > > around,
> > > > > > > covered by paper) by the patch at the end of the mail.
> > > > > > > 
> > > > > > > We already have a story trying to enable much less ambitious
> > > > > > > option
> > > > > > > -fno-strict-overflow, see r259045 and the revert in r259422.  I
> > > > > > > do
> > > > > > > not
> > > > > > > see other way than try one more time.  Too many places in kernel
> > > > > > > depend on the correctly wrapping 2-complement arithmetic, among
> > > > > > > others
> > > > > > > are callweel and scheduler.
> > > > > 
> > > > > Rather than depending on a compiler option, wouldn't it be
> > > > > better/more
> > > > > robust to change ticks to unsigned, which has specified wrapping
> > > > > behavior?
> > > > 
> > > > Yes, but non-trivial.  It's also not limited to ticks.  Since the
> > > > compiler
> > > > knows when it would apply these optimizations, it would be nice if it
> > > > could
> > > > warn instead (GCC apparently has a warning, but clang does not). 
> > > > Having
> > > > people do a manual audit of every signed integer expression in the
> > > > tree
> > > > will take a long time.
> > > 
> > > I think I misunderstood the problem as being limited to ticks,
> > > which is probably only one symptom of a fundamental change in behaviour
> > > of the compiler.
> > > Still, it might be worthwhile start looking at ints that ought to be
> > > implemented as u_int
> > 
> > I actually agree, I just think we are stuck with -fwrapv in the interval,
> > but it's probably not a short interval.  I think converting ticks to
> > unsigned would be a good first start.
> 
> For the record, I agree.  However, I suspect that attempts to do so will
> have a non trivial number of bugs introduced.  We have a track record of
> recurring problems with tcp sequence number space arithmetic and tcp
> timing, partly because the wraparounds happens infrequently.

BTW; anybody working on this will want to run with  kern.hz="100000"  in 
loader.conf (or higher).  Having the clock tick 100 times faster speeds the 
rollover up from every ~25 days to every ~6 hours.  I don't know what the 
practical limit is but at some point it will cause sufficient pain due to 
contention that it won't be useful.

-- 
Peter Wemm - peter_at_wemm.org; peter_at_FreeBSD.org; peter_at_yahoo-inc.com; KI6FJV
UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246