lkml.org 
[lkml]   [2016]   [Feb]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Crashes with 874bbfe600a6 in 3.18.25
From
Date
On Wed, 2016-02-03 at 12:06 -0500, Tejun Heo wrote:
> On Wed, Feb 03, 2016 at 06:01:53PM +0100, Mike Galbraith wrote:
> > Hm, so it's ok to queue work to an offline CPU? What happens if it
> > doesn't come back for an eternity or two?
>
> Right now, it just loses affinity....

WRT affinity...

Somebody somewhere queues a delayed work, a timer is started on CPUX,
work is targeted at CPUX. Now wash/rinse/repeat mod_delayed_work()
along with migrations. Should __queue_delayed_work() not refrain from
altering dwork->cpu once set?

I'm also wondering why 22b886dd only applies to kernels >= 4.2.

<quote>
Regardless of the previous CPU a timer was on, add_timer_on()
currently simply sets timer->flags to the new CPU. As the caller must
be seeing the timer as idle, this is locally fine, but the timer
leaving the old base while unlocked can lead to race conditions as
follows.

Let's say timer was on cpu 0.

cpu 0 cpu 1
-----------------------------------------------------------------------------
del_timer(timer) succeeds
del_timer(timer)
lock_timer_base(timer) locks cpu_0_base
add_timer_on(timer, 1)
spin_lock(&cpu_1_base->lock)
timer->flags set to cpu_1_base
operates on @timer operates on @timer
</quote>

What's the difference between...
timer->flags = (timer->flags & ~TIMER_BASEMASK) | cpu;
and...
timer_set_base(timer, base);

...that makes that fix unneeded prior to 4.2? We take the same locks
in < 4.2 kernels, so seemingly both will diddle concurrently above.

-Mike

\
 
 \ /
  Last update: 2016-02-04 11:21    [W:0.142 / U:0.432 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site