Messages in this thread | | | Date | Wed, 12 Feb 2014 10:16:57 -0500 | From | Tejun Heo <> | Subject | Re: [PATCH] edac, poll timeout cannot be zero |
| |
Hello,
On Wed, Feb 12, 2014 at 04:07:48PM +0100, Borislav Petkov wrote: > While testing, however, I keep seeing the splat below and that's: > > if (WARN_ON(!list_empty(&work->entry))) { > spin_unlock(&pwq->pool->lock); > return; > } > > and there seems to be some interference with edac_mc_workq_setup() > which does mod_delayed_work() and then the workqueue callback > edac_mc_workq_function() which does queue_delayed_work(). > > What I'm seeing in the splat is that when the timer fires to run the > delayed work, __queue_work() complains that the work list is not empty > even though we've done mod_delayed_work() which is supposed to cancel > any pending work. > > Tejun, any ideas what's happening? Do we need synchronization here or do > you have a _sync version of mod_delayed_work() which makes sure any work > is cancelled?
No, you don't need to. All workqueue operations should be able to synchronize with each other.
> Or does this mean that once the work is getting queued from the timer > callback delayed_work_timer_fn, it cannot be cancelled anymore? Or > something else I'm missing...?
Looking at edac_mc_workq_setup().... it contains INIT_DELAYED_WORK(). Does this race with other workqueue operations on the work item? If so, it of course breaks. It's like doing spin_lock_init() while other spinlock operations are in progress.
Thanks.
-- tejun
| |