On Wed, Apr 04, 2007 at 11:30:48PM +0200, Thomas Gleixner wrote:
> On Wed, 2007-04-04 at 23:11 +0200, Adrian Bunk wrote:
> > On Wed, Mar 14, 2007 at 11:00:12AM +0100, Thomas Gleixner wrote:
> > > hrtimer_forward() does not check for the possible overflow of
> > > timer->expires. This can happen on
On Wed, 2007-04-04 at 23:11 +0200, Adrian Bunk wrote:
> On Wed, Mar 14, 2007 at 11:00:12AM +0100, Thomas Gleixner wrote:
> > hrtimer_forward() does not check for the possible overflow of
> > timer->expires. This can happen on 64 bit machines with large interval
> > values and results currently in a
On Wed, Mar 14, 2007 at 11:00:12AM +0100, Thomas Gleixner wrote:
> hrtimer_forward() does not check for the possible overflow of
> timer->expires. This can happen on 64 bit machines with large interval
> values and results currently in an endless loop in the softirq because
> the expiry value becom
Thomas Gleixner wrote:
> On Sun, 2007-03-18 at 17:53 -0400, Chuck Ebbert wrote:
Just to be clear: this replaces the earlier patch, right?
>>> This replaces the fix Andrew did.
>>>
>>> http://marc.info/?l=linux-kernel&m=117407812411997&w=2
>>>
>> Right, but is the original "Prevent DOS" patch f
On Sun, 2007-03-18 at 17:53 -0400, Chuck Ebbert wrote:
> >> Just to be clear: this replaces the earlier patch, right?
> >
> > This replaces the fix Andrew did.
> >
> > http://marc.info/?l=linux-kernel&m=117407812411997&w=2
> >
>
> Right, but is the original "Prevent DOS" patch from you still ne
Thomas Gleixner wrote:
> On Sun, 2007-03-18 at 17:16 -0400, Chuck Ebbert wrote:
>> Thomas Gleixner wrote:
>>> I'd prefer this one: The maximum seconds value we can handle on 32bit is
>>> LONG_MAX.
>>>
>>> diff --git a/include/linux/ktime.h b/include/linux/ktime.h
>>> index c68c7ac..248305b 100644
>
On Sun, 2007-03-18 at 17:16 -0400, Chuck Ebbert wrote:
> Thomas Gleixner wrote:
> >
> > I'd prefer this one: The maximum seconds value we can handle on 32bit is
> > LONG_MAX.
> >
> > diff --git a/include/linux/ktime.h b/include/linux/ktime.h
> > index c68c7ac..248305b 100644
> > --- a/include/lin
Thomas Gleixner wrote:
>
> I'd prefer this one: The maximum seconds value we can handle on 32bit is
> LONG_MAX.
>
> diff --git a/include/linux/ktime.h b/include/linux/ktime.h
> index c68c7ac..248305b 100644
> --- a/include/linux/ktime.h
> +++ b/include/linux/ktime.h
> @@ -57,7 +57,11 @@ typedef u
On Fri, 2007-03-16 at 12:43 -0800, Andrew Morton wrote:
> On Wed, 14 Mar 2007 11:00:12 +0100 Thomas Gleixner <[EMAIL PROTECTED]> wrote:
>
> > rtimer_forward() does not check for the possible overflow of
> > timer->expires. This can happen on 64 bit machines with large interval
> > values and resul
On Wed, 14 Mar 2007 11:00:12 +0100 Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> rtimer_forward() does not check for the possible overflow of
> timer->expires. This can happen on 64 bit machines with large interval
> values and results currently in an endless loop in the softirq because
> the expir
* Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> hrtimer_forward() does not check for the possible overflow of
> timer->expires. This can happen on 64 bit machines with large interval
> values and results currently in an endless loop in the softirq because
> the expiry value becomes negative and
hrtimer_forward() does not check for the possible overflow of
timer->expires. This can happen on 64 bit machines with large interval
values and results currently in an endless loop in the softirq because
the expiry value becomes negative and therefor the timer is expired all
the time.
Check for th
12 matches
Mail list logo