On Thursday, December 17, 2015, Mike Snitzer <<a href="mailto:snitzer@redhat.com">snitzer@redhat.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, Dec 17 2015 at 10:50am -0500, Tejun Heo <<a href="javascript:;" onclick="_e(event, 'cvml', 'tj@kernel.org')">tj@kernel.org</a>> wrote: > Hello, Nikolay. > > On Thu, Dec 17, 2015 at 05:43:12PM +0200, Nikolay Borisov wrote: > > Right, but my initial understanding was that when canceling the delayed > > work and then issuing flush_workqueue would act the same way as if > > cancel_delayed_work_sync is called wrt to this particular delayed item, no? > > Not necessarily. cancel_delayed_work() cancels whatever is currently > pending. flush_workqueue() flushes whatever is pending and in flight > at the time of invocation. Imagine the following scenario. > > 1. Work item is running but hasn't requeued itself yet. > > 2. cancel_delayed_work_sync() doesn't do anything as it's not pending. Did you mean cancel_delayed_work()? > 3. flush_workqueue() starts and waits for the running instance. > > 4. The running instance requeues itself but this isn't included in the > scope of the above flush_workqueue(). > > 5. flush_workqueue() returns when the work item is finished (but it's > still queued). Hmm, the comment above cancel_delayed_work() is pretty misleading then: * Note: * The work callback function may still be running on return, unless * it returns %true and the work doesn't re-arm itself. Explicitly flush or * use cancel_delayed_work_sync() to wait on it. Given dm-thin.c:pool_postsuspend() does: cancel_delayed_work(&pool->waker); cancel_delayed_work(&pool->no_space_timeout); flush_workqueue(pool->wq); I wouldn't have thought cancel_delayed_work_sync() was needed. </blockquote><div> </div><div>Ping as Tejun might have missed this email. I'm also interested in knowing the logic behind the comment.</div>