aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/media/cec
diff options
context:
space:
mode:
authorHans Verkuil <hverkuil-cisco@xs4all.nl>2020-09-08 12:02:53 +0200
committerMauro Carvalho Chehab <mchehab+huawei@kernel.org>2020-09-10 14:05:10 +0200
commit288eceb0858323d66bff03cf386630a797b248ad (patch)
treecfcbcde01bdb458367ddd1a6351f880f9d78f179 /drivers/media/cec
parentmedia: mceusb: Avoid GFP_ATOMIC where it is not needed (diff)
downloadlinux-dev-288eceb0858323d66bff03cf386630a797b248ad.tar.xz
linux-dev-288eceb0858323d66bff03cf386630a797b248ad.zip
media: cec-adap.c: don't use flush_scheduled_work()
For some inexplicable reason I decided to call flush_scheduled_work() instead of cancel_delayed_work_sync(). The problem with that is that flush_scheduled_work() waits for *all* queued scheduled work to be completed instead of just the work itself. This can cause a deadlock if a CEC driver also schedules work that takes the same lock. See the comments for flush_scheduled_work() in linux/workqueue.h. This is exactly what has been observed a few times. This patch simply replaces flush_scheduled_work() by cancel_delayed_work_sync(). Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Cc: <stable@vger.kernel.org> # for v5.8 and up Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Diffstat (limited to 'drivers/media/cec')
-rw-r--r--drivers/media/cec/core/cec-adap.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/drivers/media/cec/core/cec-adap.c b/drivers/media/cec/core/cec-adap.c
index 4efe8014445e..926d65db6d3e 100644
--- a/drivers/media/cec/core/cec-adap.c
+++ b/drivers/media/cec/core/cec-adap.c
@@ -1199,7 +1199,7 @@ void cec_received_msg_ts(struct cec_adapter *adap,
/* Cancel the pending timeout work */
if (!cancel_delayed_work(&data->work)) {
mutex_unlock(&adap->lock);
- flush_scheduled_work();
+ cancel_delayed_work_sync(&data->work);
mutex_lock(&adap->lock);
}
/*