workqueue: fix ordered workqueues in NUMA setups
authorTejun Heo <tj@kernel.org>
Thu, 5 Sep 2013 16:30:04 +0000 (12:30 -0400)
committerTejun Heo <tj@kernel.org>
Fri, 22 Nov 2013 23:14:02 +0000 (18:14 -0500)
commit8a2b75384444488fc4f2cbb9f0921b6a0794838f
treec4b39daad8de264be08beec77621048e9b9fb9ed
parent91151228065354a050fd0d190aefdd662a0580aa
workqueue: fix ordered workqueues in NUMA setups

An ordered workqueue implements execution ordering by using single
pool_workqueue with max_active == 1.  On a given pool_workqueue, work
items are processed in FIFO order and limiting max_active to 1
enforces the queued work items to be processed one by one.

Unfortunately, 4c16bd327c ("workqueue: implement NUMA affinity for
unbound workqueues") accidentally broke this guarantee by applying
NUMA affinity to ordered workqueues too.  On NUMA setups, an ordered
workqueue would end up with separate pool_workqueues for different
nodes.  Each pool_workqueue still limits max_active to 1 but multiple
work items may be executed concurrently and out of order depending on
which node they are queued to.

Fix it by using dedicated ordered_wq_attrs[] when creating ordered
workqueues.  The new attrs match the unbound ones except that no_numa
is always set thus forcing all NUMA nodes to share the default
pool_workqueue.

While at it, add sanity check in workqueue creation path which
verifies that an ordered workqueues has only the default
pool_workqueue.

Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Libin <huawei.libin@huawei.com>
Cc: stable@vger.kernel.org
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
kernel/workqueue.c