Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1294062
| From | Mike Snitzer <snitzer@redhat.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: corruption causing crash in __queue_work |
| Date | 2015-12-17 18:20 +0100 |
| Message-ID | <qGKnD-2nS-1@gated-at.bofh.it> (permalink) |
| References | (5 earlier) <qFI4x-2Ex-1@gated-at.bofh.it> <qGEid-6Cx-15@gated-at.bofh.it> <qGIOR-1gS-11@gated-at.bofh.it> <qGIYy-1kc-11@gated-at.bofh.it> <qGJ8e-1nC-21@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Thu, Dec 17 2015 at 10:50am -0500,
Tejun Heo <tj@kernel.org> 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: corruption causing crash in __queue_work Nikolay Borisov <kernel@kyup.com> - 2015-12-14 09:50 +0100
Re: corruption causing crash in __queue_work Mike Snitzer <snitzer@redhat.com> - 2015-12-14 16:40 +0100
Re: corruption causing crash in __queue_work Nikolay Borisov <kernel@kyup.com> - 2015-12-14 21:20 +0100
Re: corruption causing crash in __queue_work Mike Snitzer <snitzer@redhat.com> - 2015-12-14 21:40 +0100
Re: corruption causing crash in __queue_work Nikolay Borisov <kernel@kyup.com> - 2015-12-17 11:50 +0100
Re: corruption causing crash in __queue_work Tejun Heo <tj@kernel.org> - 2015-12-17 16:40 +0100
Re: corruption causing crash in __queue_work Nikolay Borisov <kernel@kyup.com> - 2015-12-17 16:50 +0100
Re: corruption causing crash in __queue_work Tejun Heo <tj@kernel.org> - 2015-12-17 17:00 +0100
Re: corruption causing crash in __queue_work Mike Snitzer <snitzer@redhat.com> - 2015-12-17 18:20 +0100
Re: corruption causing crash in __queue_work Tejun Heo <tj@kernel.org> - 2015-12-21 22:50 +0100
Re: corruption causing crash in __queue_work Tejun Heo <tj@kernel.org> - 2015-12-21 22:50 +0100
csiph-web