Re: [Query]: delayed wq not killed completely with cancel_delayed_work_sync()

[Viresh Kumar <viresh.kumar@linaro.org>]

On 10-06-15, 16:07, Tejun Heo wrote:
> It's not a race per-se.  It's just that cancel[_delayed]_work_sync()
> doesn't disable the work item after it got cancelled and the work item
> can be reused afterwards by queueing it again.  If you don't shut down
> somebody queueing it again (excluding the work itself), the work item
> is being simply being reactivated after being cancelled.

Right, it might be wrong in my case to use any such routines. As the
call sites need to fix this problem, a race or whatever.

> This fits some use cases and even for full shut down cases, plugging
> the external queueing source is often necessary no matter what, so I'm
> a bit torn about introuding another cancel function.  Regardless,
> let's first debug this one properly.

Got it.

> Hmmm.... that's pretty specific.  The deferring is implemented from
> the timer side, so as long as timer doesn't provide a mechanism to do
> collective deferring (ie. deferring across multiple cpus), I don't
> think it makes sense for wq to try to implement that.  :(

Fair enough. And it would be difficult to have something like this in
timers AFAICT. With timers, we choose the target CPU when the timer is
enqueued and so a single timer for a group of CPUs wouldn't work.

What I can do right away, is stop using per-cpu delayed work and use
per-cpu timers instead. And keep a single work which can be queued
from any of these CPUs. That will avoid queuing per-cpu works (might
be less racy). Might be worth giving a try.

Anyway, thanks for patience :)

-- 
viresh