Messages in this thread | | | From | Boqun Feng <> | Subject | [RFC 0/2] Re-entrace of a work when requeued to a different workqueue | Date | Fri, 8 Oct 2021 18:04:52 +0800 |
| |
Hi Tejun,
I found out a possible re-entrace case of a work item:
queue_work_on(0, WQ1, W); // after a worker picks up W and clear the pending bit queue_work_on(1, WQ2, W); // workers on CPU0 and CPU1 will execute W in the same time.
To make this happen, work W must be queued to different workqueues (WQ1 & WQ2), which may look weird, but IIUC, we don't disallow it?
I'm sending this patchset out to see whether 1) this is by design (sane users of workqueues should guarantee no concurrent queuing one work on two workqueues) or 2) this is a real problem that we should fix. If it's 2), then I have a straight-forward fix in patch #2, which needs some discussion because I changes the queue_work_on() semantics a little bit: if WQ1 is a unbound workqueue and WQ2 is a bound one, my change makes the second queue_work_on() in the above case effectively queue W on WQ1, which I'm not sure is a desired change.
Patch #1 contains a simple reproduce of the re-entrance case, which is of course not for merge.
Regards, Boqun
Boqun Feng (2): NOT FOR MERGE: A selftest shows that re-entrance can happen workqueue: Fix work re-entrance when requeue to a different workqueue
kernel/workqueue.c | 43 ++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 42 insertions(+), 1 deletion(-)
-- 2.32.0
| |