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, 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 64 bit
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
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
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 becomes
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 an
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=117407812411997=2
>>>
>> Right, but is the original "Prevent DOS" patch from
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=117407812411997=2
> >
>
> Right, but is the original "Prevent DOS" patch from you still
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
> > ---
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
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 union {
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/linux/ktime.h
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: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-kernelm=117407812411997w=2
Right, but is the original Prevent DOS patch from you still needed?
Or did
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-kernelm=117407812411997w=2
Right, but is the original Prevent DOS patch from you still needed?
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
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
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 expiry
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 results
* 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
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
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
* 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
24 matches
Mail list logo
