cancel_rearming_delayed_work{queue} is broken, because it is
possible to enter an infinite loop if:
We call the function on a work that is currently not executing or pending.
But, as this is a synchronization function and as its only purpose
is to synchronize the work, that should not loop infinite.
This patch rewrites the function.
It now first cancels the work, but throws the retval of that function
away, because it is meaningless in this context. (The retval is 1,
if the work was pending and 0, if not)
After that we flush the queue to make sure any work function returns.
Now, if it was indeed running, it rescheduled itself. That is caught
by the test_bit(). If it rescheduled itself, we have the schedule-delay
time to cancel the work again (without it rescheduling itself again).
So we redo the loop. Most likely it will succeed on the
second loop iteration at least.
Signed-off-by: Michael Buesch <[email protected]>
Index: wireless-dev-dscapeports/kernel/workqueue.c
===================================================================
--- wireless-dev-dscapeports.orig/kernel/workqueue.c 2006-06-13 14:44:16.000000000 +0200
+++ wireless-dev-dscapeports/kernel/workqueue.c 2006-07-11 00:19:06.000000000 +0200
@@ -461,8 +461,10 @@
void cancel_rearming_delayed_workqueue(struct workqueue_struct *wq,
struct work_struct *work)
{
- while (!cancel_delayed_work(work))
+ do {
+ cancel_delayed_work(work);
flush_workqueue(wq);
+ } while (test_bit(0, &work->pending));
}
EXPORT_SYMBOL(cancel_rearming_delayed_workqueue);
--
Greetings Michael.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
