On 06/04/2017 09:17 AM, Thomas Gleixner wrote:
On Fri, 2 Jun 2017, Haris Okanovic wrote:
On 05/26/2017 03:50 PM, Thomas Gleixner wrote:
static void expire_timers(struct timer_base *base)
{
struct hlist_head *head;
+ int expCount = base->expired_count;
No camel case for
On 06/04/2017 09:17 AM, Thomas Gleixner wrote:
On Fri, 2 Jun 2017, Haris Okanovic wrote:
On 05/26/2017 03:50 PM, Thomas Gleixner wrote:
static void expire_timers(struct timer_base *base)
{
struct hlist_head *head;
+ int expCount = base->expired_count;
No camel case for
On Fri, 2 Jun 2017, Haris Okanovic wrote:
> On 05/26/2017 03:50 PM, Thomas Gleixner wrote:
> > > > static void expire_timers(struct timer_base *base)
> > > > {
> > > > struct hlist_head *head;
> > > > + int expCount = base->expired_count;
> >
> > No camel case for heavens sake!
>
On Fri, 2 Jun 2017, Haris Okanovic wrote:
> On 05/26/2017 03:50 PM, Thomas Gleixner wrote:
> > > > static void expire_timers(struct timer_base *base)
> > > > {
> > > > struct hlist_head *head;
> > > > + int expCount = base->expired_count;
> >
> > No camel case for heavens sake!
>
On 05/26/2017 03:50 PM, Thomas Gleixner wrote:
On Fri, 26 May 2017, Haris Okanovic wrote:
Oh crap. I think I see the problem. I decrement expired_count before
processing the list. Dropping the lock permits another run of
tick_find_expired()->find_expired_timers() in the middle of
On 05/26/2017 03:50 PM, Thomas Gleixner wrote:
On Fri, 26 May 2017, Haris Okanovic wrote:
Oh crap. I think I see the problem. I decrement expired_count before
processing the list. Dropping the lock permits another run of
tick_find_expired()->find_expired_timers() in the middle of
On 2017-05-26 19:16:07 [+0200], Anna-Maria Gleixner wrote:
> This reverts commit 032f93cae150a.
>
> The problem is that the look ahead optimization from the tick timer
> interrupt context can race with the softirq thread expiring timer. As
> a consequence the temporary hlist heads which hold the
On 2017-05-26 19:16:07 [+0200], Anna-Maria Gleixner wrote:
> This reverts commit 032f93cae150a.
>
> The problem is that the look ahead optimization from the tick timer
> interrupt context can race with the softirq thread expiring timer. As
> a consequence the temporary hlist heads which hold the
On Fri, 26 May 2017, Haris Okanovic wrote:
> Oh crap. I think I see the problem. I decrement expired_count before
> processing the list. Dropping the lock permits another run of
> tick_find_expired()->find_expired_timers() in the middle of __expire_timers()
> since it uses expired_count==0 as a
On Fri, 26 May 2017, Haris Okanovic wrote:
> Oh crap. I think I see the problem. I decrement expired_count before
> processing the list. Dropping the lock permits another run of
> tick_find_expired()->find_expired_timers() in the middle of __expire_timers()
> since it uses expired_count==0 as a
Oh crap. I think I see the problem. I decrement expired_count before
processing the list. Dropping the lock permits another run of
tick_find_expired()->find_expired_timers() in the middle of
__expire_timers() since it uses expired_count==0 as a condition.
This should fix it, but I'll wait for
Oh crap. I think I see the problem. I decrement expired_count before
processing the list. Dropping the lock permits another run of
tick_find_expired()->find_expired_timers() in the middle of
__expire_timers() since it uses expired_count==0 as a condition.
This should fix it, but I'll wait for
On Fri, 26 May 2017, Haris Okanovic wrote:
> Anna-Maria,
>
> Look-ahead is implemented by tick_find_expired() and expiry by __run_timers(),
> both of which hold timer_base::lock (raw spin lock) while running. Those two
> routines shouldn't be able to run simultaneously on the same timer_base.
On Fri, 26 May 2017, Haris Okanovic wrote:
> Anna-Maria,
>
> Look-ahead is implemented by tick_find_expired() and expiry by __run_timers(),
> both of which hold timer_base::lock (raw spin lock) while running. Those two
> routines shouldn't be able to run simultaneously on the same timer_base.
Anna-Maria,
Look-ahead is implemented by tick_find_expired() and expiry by
__run_timers(), both of which hold timer_base::lock (raw spin lock)
while running. Those two routines shouldn't be able to run
simultaneously on the same timer_base. Are you sure the race isn't in
another code path?
Anna-Maria,
Look-ahead is implemented by tick_find_expired() and expiry by
__run_timers(), both of which hold timer_base::lock (raw spin lock)
while running. Those two routines shouldn't be able to run
simultaneously on the same timer_base. Are you sure the race isn't in
another code path?
This reverts commit 032f93cae150a.
The problem is that the look ahead optimization from the tick timer
interrupt context can race with the softirq thread expiring timer. As
a consequence the temporary hlist heads which hold the to expire
timers are overwritten and the timers which are already
This reverts commit 032f93cae150a.
The problem is that the look ahead optimization from the tick timer
interrupt context can race with the softirq thread expiring timer. As
a consequence the temporary hlist heads which hold the to expire
timers are overwritten and the timers which are already
18 matches
Mail list logo
