lkml.org 
[lkml]   [2011]   [Nov]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] clocksource: Avoid selecting mult values that might overflow when adjusted
    On Thu, 3 Nov 2011, John Stultz wrote:

    > On Thu, 2011-11-03 at 10:01 -0400, John Stultz wrote:
    > > On Thu, 2011-11-03 at 14:26 +0100, Thomas Gleixner wrote:
    > > > On Thu, 3 Nov 2011, John Stultz wrote:
    > > > > On Thu, 2011-11-03 at 13:05 +0100, Thomas Gleixner wrote:
    > > > > > On Wed, 2 Nov 2011, John Stultz wrote:
    > > > > > >
    > > > > > > + WARN_ONCE(timekeeper.mult+adj >
    > > > > > > + timekeeper.clock->mult + timekeeper.clock->maxadj,
    > > > > > > + "Adjusting more then 11%%");
    > > > > >
    > > > > > Shouldn't we rather limit the update instead of just warn and overflow ?
    > > > >
    > > > > Well, I'm hesitant to commit to that, just yet. So I figured I'd start
    > > > > with the warning.
    > > >
    > > > OTOH, we know right there that we might warp 32bit and confuse the
    > > > hell out of timekeeping, which is not a real good thing either.
    > >
    > > Oh certainly, but two things:
    > > 1) The 11% max is not the actual overflow edge. Its just calculated as
    > > safe. The overflow could as far out as ~22%.
    > >
    > > 2) This is the first case in however many years I've heard of of mult
    > > overflowing. So before we go changing the NTP code (which is really
    > > terribly complex, but has been working fairly well for awhile) I want to
    > > have some sense that the 11% max adjustment assumption is really
    > > correct.
    > >
    > > But maybe I'm being too conservative? If we do limit the adjustment
    > > keeping the warning, I guess we'd know why things blew up on previously
    > > working machines.
    >
    > Oh, and the other bit is that not all clocksources have been converted
    > over to using clocksource_register_hz/khz, so some may be using very
    > small shift values, which could more easily hit large % mult adjustment
    > (due to the resulting coarseness of each integer change) that wouldn't
    > cause overflows.

    Fair enough. I'm queuing it.


    \
     
     \ /
      Last update: 2011-11-03 15:51    [W:0.030 / U:0.072 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site