]> git.baikalelectronics.ru Git - kernel.git/commit
workqueue: don't skip lockdep work dependency in cancel_work_sync()
authorTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Fri, 29 Jul 2022 04:30:23 +0000 (13:30 +0900)
committerTejun Heo <tj@kernel.org>
Tue, 16 Aug 2022 16:27:35 +0000 (06:27 -1000)
commita1a83b74f636596e6e4968d3c66ce3548373d1e3
tree2b5865f838a419bf631a14a3ebcfa0d7af20fcd0
parent34a3249ab33a1690f58cd6e91a0208887337d3e0
workqueue: don't skip lockdep work dependency in cancel_work_sync()

Like Hillf Danton mentioned

  syzbot should have been able to catch cancel_work_sync() in work context
  by checking lockdep_map in __flush_work() for both flush and cancel.

in [1], being unable to report an obvious deadlock scenario shown below is
broken. From locking dependency perspective, sync version of cancel request
should behave as if flush request, for it waits for completion of work if
that work has already started execution.

  ----------
  #include <linux/module.h>
  #include <linux/sched.h>
  static DEFINE_MUTEX(mutex);
  static void work_fn(struct work_struct *work)
  {
    schedule_timeout_uninterruptible(HZ / 5);
    mutex_lock(&mutex);
    mutex_unlock(&mutex);
  }
  static DECLARE_WORK(work, work_fn);
  static int __init test_init(void)
  {
    schedule_work(&work);
    schedule_timeout_uninterruptible(HZ / 10);
    mutex_lock(&mutex);
    cancel_work_sync(&work);
    mutex_unlock(&mutex);
    return -EINVAL;
  }
  module_init(test_init);
  MODULE_LICENSE("GPL");
  ----------

The check this patch restores was added by commit f6409590e16c4810
("workqueue: Catch more locking problems with flush_work()").

Then, lockdep's crossrelease feature was added by commit 14f93519becdde37
("locking/lockdep: Implement the 'crossrelease' feature"). As a result,
this check was once removed by commit ead1792cd2e9b288 ("workqueue: Remove
now redundant lock acquisitions wrt. workqueue flushes").

But lockdep's crossrelease feature was removed by commit 60277235f07f3f66
("locking/lockdep: Remove the cross-release locking checks"). At this
point, this check should have been restored.

Then, commit b2ba491a2f8fd553 ("workqueue: skip lockdep wq dependency in
cancel_work_sync()") introduced a boolean flag in order to distinguish
flush_work() and cancel_work_sync(), for checking "struct workqueue_struct"
dependency when called from cancel_work_sync() was causing false positives.

Then, commit ad1fbae7f71a93fa ("workqueue: re-add lockdep dependencies for
flushing") tried to restore "struct work_struct" dependency check, but by
error checked this boolean flag. Like an example shown above indicates,
"struct work_struct" dependency needs to be checked for both flush_work()
and cancel_work_sync().

Link: https://lkml.kernel.org/r/20220504044800.4966-1-hdanton@sina.com
Reported-by: Hillf Danton <hdanton@sina.com>
Suggested-by: Lai Jiangshan <jiangshanlai@gmail.com>
Fixes: ad1fbae7f71a93fa ("workqueue: re-add lockdep dependencies for flushing")
Cc: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: Tejun Heo <tj@kernel.org>
kernel/workqueue.c