Re: [Patch] Re: Nasty suprise with uptime

[Petr Vandrovec]

On 31 Oct 01 at 15:39, Richard B. Johnson wrote:
> A fix exists, though. The existing, possibly wrong, boot time could
> be grabbed during the set-time sys-call, the difference between the
> existing (wrong) time and the boot time could be calculated, the
> new (correct) time could be set, then the boot-time would be changed
> to the new correct time, minus the calculated difference. This
> would result in a correct boot-time.
> 
>     dif_time = time - boot_time;
>         time = new_time;
>         boot_time = time - dif_time;
> 
> Uptime could then be present time minus boot time. No mucking with
> timer ticks are required.

Hi,
  this reminds me. Year or so ago there was patch from someone, which 
detected jiffies overflow in /proc/uptime proc_read() code, so only thing
you had to do was run 'uptime', 'w', 'top' or something like that
every 497 days - you can schedule it as cron job for Jan 1, 0:00:00,
to find some workoholics.

  Patch was something like:

...  
static unsigned long long jiffies_hi = 0;
static unsigned long old_jiffies = 0;
unsigned long jiffy_cache;

/* some spinlock or inode lock or something like that */
jiffy_cache = jiffies;
if (jiffy_cache < old_jiffies) {
   jiffies_hi += 1ULL << BITS_PER_LONG;
}
old_jiffies = jiffy_cache;
grand_jiffies = jiffies_hi + jiffy_cache;
/* unlock */
/* now do division and all strange things to format number for userspace */
...

Even if you add running uptime every year to your crontab, 
it will consume less than 700,000,000 CPU cycles consumed by just 64bit
inc in timer interrupt.
                                        Best regards,
                                            Petr Vandrovec
                                            [e-mail]