Description of problem:
(quote from Oleg)
"cancel_rearming_delayed_work + flush_workqueue has the following problems:
- it hangs forever if the work doesn't rearm itsels (or if
it was never queued)
- in fact it can't cancel the auto-rearming work too, if this
work is queued on >1 CPUs. But probably we can ignore this
very exotic case.
- it can hang if called under any LOCK which could be used
by any other work which may be queued on the same wq.
We have some driver backported from upstream (like wireless stack) which have workqueue handlers like that
queue_delayed_work(my->workqueue, my->work, delay);
We can stop that such work reliable in current RHEL5. We need cancel_delayed_work_sync and cancel_delayed_work with upstream semantics.
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release. Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products. This request is not yet committed for inclusion in an Update
[RHEL5 PATCH 0/7] bz#596626: implement cancel_work_sync() and cancel_delayed_work_sync()
You can download this test kernel from http://people.redhat.com/jwilson/el5
Detailed testing feedback is always welcomed.
Created attachment 468781 [details]
test_workq kernel module
I used this module to test workqueues, old kernel hangs within minutes, with patch kernel survive a night and I terminate the test.
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.