]> git.ipfire.org Git - thirdparty/kernel/stable.git/commit
workqueue: skip lockdep wq dependency in cancel_work_sync()
authorJohannes Berg <johannes.berg@intel.com>
Wed, 22 Aug 2018 09:49:03 +0000 (11:49 +0200)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Sat, 15 Sep 2018 07:46:46 +0000 (09:46 +0200)
commitb7a3d36d6c329bf6d78326a8e89ed65d5deea063
treefaf73ac515952e11251e5985ffb101ead86b176c
parent798d80a612ddb70d5c62b767227146427e14a4be
workqueue: skip lockdep wq dependency in cancel_work_sync()

[ Upstream commit d6e89786bed977f37f55ffca11e563f6d2b1e3b5 ]

In cancel_work_sync(), we can only have one of two cases, even
with an ordered workqueue:
 * the work isn't running, just cancelled before it started
 * the work is running, but then nothing else can be on the
   workqueue before it

Thus, we need to skip the lockdep workqueue dependency handling,
otherwise we get false positive reports from lockdep saying that
we have a potential deadlock when the workqueue also has other
work items with locking, e.g.

  work1_function() { mutex_lock(&mutex); ... }
  work2_function() { /* nothing */ }

  other_function() {
    queue_work(ordered_wq, &work1);
    queue_work(ordered_wq, &work2);
    mutex_lock(&mutex);
    cancel_work_sync(&work2);
  }

As described above, this isn't a problem, but lockdep will
currently flag it as if cancel_work_sync() was flush_work(),
which *is* a problem.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
kernel/workqueue.c