diff options
author | Hans Verkuil <hverkuil-cisco@xs4all.nl> | 2023-06-12 16:58:37 +0300 |
---|---|---|
committer | Mauro Carvalho Chehab <mchehab@kernel.org> | 2023-08-10 08:58:32 +0300 |
commit | da53c36ddd3f118a525a04faa8c47ca471e6c467 (patch) | |
tree | 749b96a20331befc34c2747cc78ad6f16b51fe65 /Documentation/driver-api | |
parent | 99939beaefca29ca105900afaf81e6e9e591d2ef (diff) | |
download | linux-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