lkml.org 
[lkml]   [2001]   [Nov]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-03-22 13:12    [W:0.079 / U:3.252 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site