Re: [PATCH] cancel_rearming_delayed_work infinite loop fix

2006-07-11 Thread Herbert Xu
Michael Buesch [EMAIL PROTECTED] wrote:
 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.

Why are you calling it on a work that was never scheduled? Sounds like
a bug to me.

 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));

This is broken.  If the work just starts running before your test_bit
you'd exit without cancelling it properly.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] cancel_rearming_delayed_work infinite loop fix

2006-07-10 Thread Michael Buesch
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.c2006-06-13 
14:44:16.0 +0200
+++ wireless-dev-dscapeports/kernel/workqueue.c 2006-07-11 00:19:06.0 
+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 netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html