When logging the control values through VIDIOC_LOG_STATUS you could
get into a potential deadlock situation in the vivid driver:
[Wed May 8 10:02:06 2024] Possible unsafe locking scenario:
[Wed May 8 10:02:06 2024] CPU0 CPU1
[Wed May 8 10:02:06 2024] ---- ----
[Wed May 8 10:02:06 2024] lock(vivid_ctrls:1620:(hdl_vid_cap)->_lock);
[Wed May 8 10:02:06 2024] lock(vivid_ctrls:1608:(hdl_user_vid)->_lock);
[Wed May 8 10:02:06 2024] lock(vivid_ctrls:1620:(hdl_vid_cap)->_lock);
[Wed May 8 10:02:06 2024] lock(vivid_ctrls:1608:(hdl_user_vid)->_lock);
That's because both the main control handler was locked and the
inner control handler containing the control that you want to log.
In this particular case there is no need to lock the inner control
handler since it is guaranteed that that handler won't delete controls
unexpectedly.
Fixes: 9801b5b28c692 ("media: v4l2-ctrls: show all owned controls in log_status")
Signed-off-by: Hans Verkuil <hverkuil-cisco@xxxxxxxxx>
---
drivers/media/v4l2-core/v4l2-ctrls-core.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-ctrls-core.c b/drivers/media/v4l2-core/v4l2-ctrls-core.c
index c59dd691f79f6..4e6748bd419cf 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls-core.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls-core.c
@@ -2518,11 +2518,7 @@ static void log_ctrl(const struct v4l2_ctrl_handler *hdl,
pr_info("%s%s%s: ", prefix, colon, ctrl->name);
- if (ctrl->handler != hdl)
- v4l2_ctrl_lock(ctrl);
ctrl->type_ops->log(ctrl);
- if (ctrl->handler != hdl)
- v4l2_ctrl_unlock(ctrl);
if (ctrl->flags & (V4L2_CTRL_FLAG_INACTIVE |
V4L2_CTRL_FLAG_GRABBED |
--
2.43.0
