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

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

On 09-06-15, 16:48, Viresh Kumar wrote:
> On 09-06-15, 16:43, Viresh Kumar wrote:
> > HI Tejun,
> >
> > We had few races in cpufreq core for some time now and we
> > are looking to fix them.
> >
> > Briefly, we run a delayed_work on each cpu at a fixed interval
> > (sampling rate) and when that expires that take a look at system
> > load and adjust frequency accordingly. We also requeue the
> > delayed-works from these handlers.
> >
> > The problem we are facing is NULL pointer dereference from
> > work handler..
> >
> > Before we set the pointers to NULL and free resource (for which
> > we are seeing the crashes), we cancel the delayed works with
> > cancel_delayed_work_sync(&dwork);
> >
> > We expect the work to not fire at all once this returns, but it
> > looks like the work handler does get called..
> >
> > The mainline version of cpufreq_governor.c is a bit older than
> > what we have, but I just wanted the clarification on the routine
> > itself.
> >
> > Thanks for reading this :)

And another query:

Do we have support for this kind of scenarios in wq framework ?

- Enqueue a single delayed work for a group of CPUs (and should fire
  on any one of them). We are doing this per-cpu today in cpufreq.
- It has to be a deffered one, so that if none of the CPUs from that
  group are online, we don't fire it.
- As the per-cpu workqueue thing is unnecessary burden on CPUs.

Thanks.

-- 
viresh