summaryrefslogtreecommitdiff
path: root/drivers/media/common/videobuf2/videobuf2-dma-contig.c
diff options
context:
space:
mode:
authorHans Verkuil <hverkuil-cisco@xs4all.nl>2020-09-08 13:02:53 +0300
committerMauro Carvalho Chehab <mchehab+huawei@kernel.org>2020-09-10 15:05:10 +0300
commit288eceb0858323d66bff03cf386630a797b248ad (patch)
treecfcbcde01bdb458367ddd1a6351f880f9d78f179 /drivers/media/common/videobuf2/videobuf2-dma-contig.c
parentddecfc76979d5585847c76c4c489dcac389f86dd (diff)
downloadlinux-288eceb0858323d66bff03cf386630a797b248ad.tar.xz
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/common/videobuf2/videobuf2-dma-contig.c')
0 files changed, 0 insertions, 0 deletions