linux-kernel - Re: [PATCH] media: i2c: ov5647: use our own mutex for the ctrl lock

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <4553d9ed-ba4e-4f83-b48e-e819e7979293@oss.qualcomm.com>
Date: Mon, 1 Dec 2025 10:31:59 +0100
From: johannes.goede@....qualcomm.com
To: Xiaolei Wang <xiaolei.wang@...driver.com>, sakari.ailus@...ux.intel.com,
        dave.stevenson@...pberrypi.com, jacopo@...ndi.org, mchehab@...nel.org,
        prabhakar.mahadev-lad.rj@...renesas.com,
        laurent.pinchart@...asonboard.com, hverkuil+cisco@...nel.org
Cc: linux-media@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] media: i2c: ov5647: use our own mutex for the ctrl lock

Hi,

On 1-Dec-25 1:00 AM, Xiaolei Wang wrote:
> __v4l2_ctrl_handler_setup() and __v4l2_ctrl_modify_range()
> contains an assertion to verify that the v4l2_ctrl_handler::lock
> is held, as it should only be called when the lock has already
> been acquired. Therefore use our own mutex for the ctrl lock,
> otherwise a warning will be  reported.
> 
> Signed-off-by: Xiaolei Wang <xiaolei.wang@...driver.com>

Generally speaking as a default locking setup for sensor
drivers we are moving in the direction of removing driver
specific locks and instead using the control-handler
lock everywhere, including using it as the active state
lock, see e.g. :

https://lore.kernel.org/linux-media/20250313184314.91410-14-hdegoede@redhat.com/

which sets ov02c10->sd.state_lock = ov02c10->ctrl_handler.lock
and then removes a bunch of manual mutex_lock / unlock calls
since all ops which get called with a sd_state will already
have the lock called when operating on the active_state
(and when called in try mode they should not touch anything
needing locking).

Note if you also want to make the ctrl_handler lock
the active state lock then you need to add calls to
v4l2_subdev_init_finalize() / v4l2_subdev_cleanup()
to allocate the active-state to probe().

Regards,

Hans




> ---
>  drivers/media/i2c/ov5647.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/media/i2c/ov5647.c b/drivers/media/i2c/ov5647.c
> index e193fef4fced..4e14eefba577 100644
> --- a/drivers/media/i2c/ov5647.c
> +++ b/drivers/media/i2c/ov5647.c
> @@ -1288,9 +1288,12 @@ static int ov5647_init_controls(struct ov5647 *sensor)
>  {
>  	struct i2c_client *client = v4l2_get_subdevdata(&sensor->sd);
>  	int hblank, exposure_max, exposure_def;
> +	struct v4l2_ctrl_handler *hdl = &sensor->ctrls;
>  
>  	v4l2_ctrl_handler_init(&sensor->ctrls, 9);
>  
> +	hdl->lock = &sensor->lock;
> +
>  	v4l2_ctrl_new_std(&sensor->ctrls, &ov5647_ctrl_ops,
>  			  V4L2_CID_AUTOGAIN, 0, 1, 1, 0);
>