Re: [PATCH] Avoid time_offset overflows

From: Thomas Gleixner
Date: Sun Mar 25 2007 - 07:00:56 EST


On Sun, 2007-03-25 at 01:09 -0800, Andrew Morton wrote:
> On Sat, 24 Mar 2007 06:20:45 +0100 (CET) Roman Zippel <zippel@xxxxxxxxxxxxxx> wrote:
>
> > Hi,
> >
> > On Fri, 23 Mar 2007, john stultz wrote:
> >
> > > @@ -314,8 +314,8 @@ #endif
> > > freq_adj += time_freq;
> > > freq_adj = min(freq_adj, (s64)MAXFREQ_NSEC);
> > > time_freq = max(freq_adj, (s64)-MAXFREQ_NSEC);
> > > - time_offset = (time_offset / NTP_INTERVAL_FREQ)
> > > - << SHIFT_UPDATE;
> > > + do_div(time_offset, NTP_INTERVAL_FREQ);
> > > + time_offset <<= SHIFT_UPDATE;
> > > } /* STA_PLL */
> > > } /* txc->modes & ADJ_OFFSET */
> > > if (txc->modes & ADJ_TICK)
> >
> > This is wrong, time_offset is signed and do_div is unsigned.
> > In general I planned to do the same change, but the do_div API could use a
> > little cleanup to provide some clear function for signed/unsigned divide
> > (hopefully with a better name than div_long_long_rem_signed or
> > do_div_llr).
> >
>
> Can we do a minimal thing for 2.6.21, worry about API beautification later?

Here you go. It's ugly, but it should do the trick for now.

tglx

Index: linux-2.6/kernel/time/ntp.c
===================================================================
--- linux-2.6.orig/kernel/time/ntp.c
+++ linux-2.6/kernel/time/ntp.c
@@ -196,7 +196,7 @@ void __attribute__ ((weak)) notify_arch_
*/
int do_adjtimex(struct timex *txc)
{
- long mtemp, save_adjust;
+ long mtemp, save_adjust, rem;
s64 freq_adj, temp64;
int result;

@@ -314,7 +314,9 @@ int do_adjtimex(struct timex *txc)
freq_adj += time_freq;
freq_adj = min(freq_adj, (s64)MAXFREQ_NSEC);
time_freq = max(freq_adj, (s64)-MAXFREQ_NSEC);
- do_div(time_offset, NTP_INTERVAL_FREQ);
+ time_offset = div_long_long_rem_signed(time_offset,
+ NTP_INTERVAL_FREQ,
+ &rem);
time_offset <<= SHIFT_UPDATE;
} /* STA_PLL */
} /* txc->modes & ADJ_OFFSET */


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/