summaryrefslogtreecommitdiff
path: root/mm/memory_hotplug.c
diff options
context:
space:
mode:
authorHans Verkuil <hverkuil-cisco@xs4all.nl>2019-12-11 14:47:57 +0300
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2020-01-09 12:19:56 +0300
commit80d9e63714a43a162ce79abe33dd18a2111f3c4e (patch)
treecec6e473d2d38a85e82ed337ed38dd40e9b51f94 /mm/memory_hotplug.c
parent9a7130220ab48b251987c3ec5843116285e67b22 (diff)
downloadlinux-80d9e63714a43a162ce79abe33dd18a2111f3c4e.tar.xz
media: cec: check 'transmit_in_progress', not 'transmitting'
commit ac479b51f3f4aaa852b5d3f00ecfb9290230cf64 upstream. Currently wait_event_interruptible_timeout is called in cec_thread_func() when adap->transmitting is set. But if the adapter is unconfigured while transmitting, then adap->transmitting is set to NULL. But the hardware is still actually transmitting the message, and that's indicated by adap->transmit_in_progress and we should wait until that is finished or times out before transmitting new messages. As the original commit says: adap->transmitting is the userspace view, adap->transmit_in_progress reflects the hardware state. However, if adap->transmitting is NULL and adap->transmit_in_progress is true, then wait_event_interruptible is called (no timeout), which can get stuck indefinitely if the CEC driver is flaky and never marks the transmit-in-progress as 'done'. So test against transmit_in_progress when deciding whether to use the timeout variant or not, instead of testing against adap->transmitting. Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Fixes: 32804fcb612b ("media: cec: keep track of outstanding transmits") Cc: <stable@vger.kernel.org> # for v4.19 and up Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'mm/memory_hotplug.c')
0 files changed, 0 insertions, 0 deletions