[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1343739939.2633.34.camel@deskari>
Date: Tue, 31 Jul 2012 16:05:39 +0300
From: Tomi Valkeinen <tomi.valkeinen@...com>
To: Tejun Heo <tj@...nel.org>
Cc: linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
akpm@...ux-foundation.org, padovan@...fusion.mobi,
marcel@...tmann.org, peterz@...radead.org, mingo@...hat.com,
davem@...emloft.net, dougthompson@...ssion.com,
ibm-acpi@....eng.br, cbou@...l.ru, rui.zhang@...el.com,
Jens Axboe <axboe@...nel.dk>, Jiri Kosina <jkosina@...e.cz>,
Roland Dreier <roland@...nel.org>
Subject: Re: [PATCH 15/15] workqueue: deprecate __cancel_delayed_work()
Hi,
On Fri, 2012-07-27 at 16:55 -0700, Tejun Heo wrote:
> __cancel_delayed_work() is different from cancel_delayed_work() in
> that it uses del_timer() instead of del_timer_sync(). This adds
> confusion to already complicated flush / cancel API and given that the
> only thing delayed_work->timer does is queueing the work, the
> difference between cancel_delayed_work() and __cancel_delayed_work()
> isn't anything material.
>
> Furthermore, none of the remaining users are on hot path racing
> against high-frequency work item making the chance of actually waiting
> for delayed_work_timer_fn() very slim.
>
> Use cancel_delayed_work() instead of __cancel_delayed_work() and mark
> the latter deprecated.
I used __cancel_delayed_work() in drivers/video/omap2/dss/dsi.c as the
cancel is done in an interrupt handler. Is it safe to use
cancel_delayed_work() in atomic context? I presume not, as it uses
del_timer_sync().
Tomi
Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)
Powered by blists - more mailing lists