lkml.org 
[lkml]   [2021]   [Oct]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Subject[RFC 0/2] Re-entrace of a work when requeued to a different workqueue
Date
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

\
 
 \ /
  Last update: 2021-10-08 12:07    [W:0.134 / U:0.296 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site