(take 2) I'm not sure we've agreed enough, who'll resubmit, so here it is with WARN_ON. If it was submited already - forget it.
Jarek P. ---> IMHO cancel_rearming_delayed_work is dangerous place: - it assumes a work function always rearms (with no exception), which probably isn't explained enough now (but anyway should be checked in such loops); - probably possible (theoretical) scenario: a few work functions rearm themselves with very short, equal times; before flush_workqueue ends, their timers are already fired, so cancel_delayed_work has nothing to do. Maybe this patch could check, if I'm not dreaming... PS: of course the counter value below is a question of taste Signed-off-by: Jarek Poplawski <[EMAIL PROTECTED]> --- diff -Nurp 2.6.21-rc6-mm1-/kernel/workqueue.c 2.6.21-rc6-mm1/kernel/workqueue.c --- 2.6.21-rc6-mm1-/kernel/workqueue.c 2007-04-18 20:07:45.000000000 +0200 +++ 2.6.21-rc6-mm1/kernel/workqueue.c 2007-04-18 20:15:44.000000000 +0200 @@ -557,9 +557,12 @@ void cancel_rearming_delayed_work(struct /* Was it ever queued ? */ if (cwq != NULL) { struct workqueue_struct *wq = cwq->wq; + int i = 1000; - while (!cancel_delayed_work(dwork)) + while (!cancel_delayed_work(dwork)) { flush_workqueue(wq); + WARN_ON(!i--); + } } } EXPORT_SYMBOL(cancel_rearming_delayed_work); - 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/