On Fri, Jul 27, 2012 at 11:30:58PM +1000, Bruce Evans wrote: B> > On Fri, Jul 27, 2012 at 10:32:55PM +1000, Bruce Evans wrote: B> > B> I just noticed that there is a technical problem -- the count is read B> > B> unlocked in the KASSERT. And since the comparision is for equality, B> > B> if you lose the race reading the count when it reaches the overflow B> > B> threshold, then you won't see it overflow unless it wraps again and B> > B> you win the race next time (or later). atomic_cmpset could be used B> > B> to clamp the value at the max, but that is too much for an assertion. B> > B> > We have discussed that. As alternative I proposed: B> > B> > @@ -50,8 +51,14 @@ B> > static __inline void B> > refcount_acquire(volatile u_int *count) B> > { B> > +#ifdef INVARIANTS B> > + u_int old; B> > + old = atomic_fetchadd_int(count, 1); B> > + KASSERT(old < UINT_MAX, ("refcount %p overflowed", count)); B> > +#else B> > atomic_add_acq_int(count, 1); B> > +#endif B> > } B> > B> > Konstantin didn't like that production code differs from INVARIANTS. B> > B> > So we ended with what I committed, advocating to the fact that although B> > assertion is racy and bad panics still can occur, the "good panics" B> > would occur much more often, and a single "good panic" is enough to B> > show what's going on. B> B> Yes, it is excessive. B> B> So why do people even care about this particular overflow? There are B> many integers that can overflow in the kernel. Some binary wraparounds B> are even intentional.
Because "negative refcount" panic is very confusing in the case when one got overflow. http://lists.freebsd.org/pipermail/freebsd-net/2012-July/032822.html -- Totus tuus, Glebius. _______________________________________________ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"