Re: [PATCH 1/2] time: Fix NTP adjustment mult overflow.

2014-10-23 Thread John Stultz
On Wed, Oct 22, 2014 at 5:37 AM, Xunlei Pang wrote: > The mult memember of struct clocksource should always be a large u32 number > when calculated through > __clocksource_updatefreq_scale(). The value of (cs->mult+cs->maxadj) may > have a chance to reach very > near 0x, so it may overflow

Re: [PATCH 1/2] time: Fix NTP adjustment mult overflow.

2014-10-21 Thread Thomas Gleixner
On Tue, 21 Oct 2014, John Stultz wrote: > On Tue, Oct 21, 2014 at 3:19 AM, Thomas Gleixner wrote: > > So you adding this just for correctness reasons, not because you > > observed the problem in practice? > > This is my understanding. > > I'll work with Xunlei to make further clarifications to t

Re: [PATCH 1/2] time: Fix NTP adjustment mult overflow.

2014-10-21 Thread John Stultz
On Tue, Oct 21, 2014 at 3:19 AM, Thomas Gleixner wrote: > On Thu, 9 Oct 2014, pang.xunlei wrote: > > First of all: Please use proper line breaks in the changelog. > >> The mult memember of struct clocksource should always be a large u32 >> number when calculated through __clocksource_updatefreq_sc

Re: [PATCH 1/2] time: Fix NTP adjustment mult overflow.

2014-10-21 Thread Thomas Gleixner
On Thu, 9 Oct 2014, pang.xunlei wrote: First of all: Please use proper line breaks in the changelog. > The mult memember of struct clocksource should always be a large u32 > number when calculated through __clocksource_updatefreq_scale(). The > value of (cs->mult+cs->maxadj) may have a chance to

[PATCH 1/2] time: Fix NTP adjustment mult overflow.

2014-10-09 Thread pang.xunlei
The mult memember of struct clocksource should always be a large u32 number when calculated through __clocksource_updatefreq_scale(). The value of (cs->mult+cs->maxadj) may have a chance to reach very near 0x. For instance, 555MHz oscillator: cs->mult is 0xE6A17102, cs->maxadj is 0x195E8