Messages in this thread | | | Date | Thu, 1 Nov 2001 12:40:54 +0100 (CET) | From | Tim Schmielau <> | Subject | Re: [Patch] Re: Nasty suprise with uptime |
| |
On Thu, 1 Nov 2001, george anzinger wrote:
> Tim Schmielau wrote: > > + > > +#if BITS_PER_LONG < 48 > > + > > +u64 get_jiffies64(void) > > +{ > > + static unsigned long jiffies_hi = 0; > > + static unsigned long jiffies_last = INITIAL_JIFFIES; > > + unsigned long jiffies_tmp; > > + > > + jiffies_tmp = jiffies; /* avoid races */ > > + if (jiffies_tmp < jiffies_last) /* We have a wrap */ > > + jiffies_hi++; > > + jiffies_last = jiffies_tmp; > > + > > + return (jiffies_tmp | ((u64)jiffies_hi) << BITS_PER_LONG); > > Doesn't this need to be protected on SMP machines? What if two cpus > call get_jiffies64() at the same time... Seems like jiffies_hi could > get bumped twice instead of once. > > George >
Yes, it does, my race protection is bogus. Petr Vandrovec also pointed out that. So we do need either to a) stuff jiffies_hi and jiffies_last into one atomic type (16 bits is enough for each) or b) use locking. My next patch will use b), but I won't do it until I have resolved the most annoying stability issues. I won't have time to do this before the weekend, and don't want to bother the list too much either.
Maybe the lockups are just due to my setting of INITIAL_JIFFIES instead of waiting 471 days. The time adjustment routines are good candidates for this kind of mistakes. Any ideas anyone where else I might have forgotten to introduce INITIAL_JIFFIES ?
Tim
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |