summaryrefslogtreecommitdiff
path: root/Documentation/driver-api
diff options
context:
space:
mode:
authorHans Verkuil <hverkuil-cisco@xs4all.nl>2023-06-12 16:58:37 +0300
committerMauro Carvalho Chehab <mchehab@kernel.org>2023-08-10 08:58:32 +0300
commitda53c36ddd3f118a525a04faa8c47ca471e6c467 (patch)
tree749b96a20331befc34c2747cc78ad6f16b51fe65 /Documentation/driver-api
parent99939beaefca29ca105900afaf81e6e9e591d2ef (diff)
downloadlinux-da53c36ddd3f118a525a04faa8c47ca471e6c467.tar.xz
media: cec: core: add adap_nb_transmit_canceled() callback
A potential deadlock was found by Zheng Zhang with a local syzkaller instance. The problem is that when a non-blocking CEC transmit is canceled by calling cec_data_cancel, that in turn can call the high-level received() driver callback, which can call cec_transmit_msg() to transmit a new message. The cec_data_cancel() function is called with the adap->lock mutex held, and cec_transmit_msg() tries to take that same lock. The root cause is that the received() callback can either be used to pass on a received message (and then adap->lock is not held), or to report a canceled transmit (and then adap->lock is held). This is confusing, so create a new low-level adap_nb_transmit_canceled callback that reports back that a non-blocking transmit was canceled. And the received() callback is only called when a message is received, as was the case before commit f9d0ecbf56f4 ("media: cec: correctly pass on reply results") complicated matters. Reported-by: Zheng Zhang <zheng.zhang@email.ucr.edu> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Fixes: f9d0ecbf56f4 ("media: cec: correctly pass on reply results") Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Diffstat (limited to 'Documentation/driver-api')
0 files changed, 0 insertions, 0 deletions