Re: [PATCH v8 2/3] media: i2c: Add Sony IMX681 sensor driver

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] media: imx681: data race when reading controls in TRY state
--

commit a33b99a3eba0fc3b30bb7afedc0eb847da781102
Author: Andre Gilerson <andre.gilerson@gmail.com>

media: i2c: Add Sony IMX681 sensor driver

This commit adds a V4L2 sub-device driver for the Sony IMX681 sensor. It
supports 10-bit Bayer formats over a two-lane CSI-2 bus with a single
3844x2640 mode at 30 fps, along with various controls including flips.

> diff --git a/drivers/media/i2c/imx681.c b/drivers/media/i2c/imx681.c
> new file mode 100644
> --- /dev/null
> +++ b/drivers/media/i2c/imx681.c
[ ... ]
> +static u32 imx681_get_format_code(struct imx681 *imx681)
> +{
> +	return imx681_mbus_codes[(imx681->vflip->val ? 2 : 0) |
> +				 (imx681->hflip->val ? 1 : 0)];
> +}

[Severity: Medium]
Is there a potential data race here when reading the control values
during TRY state operations?

When a userspace process calls VIDIOC_SUBDEV_ENUM_MBUS_CODE or
VIDIOC_SUBDEV_S_FMT with V4L2_SUBDEV_FORMAT_TRY, the V4L2 core locks the
file handle's TRY state, but not the control handler. Concurrently, if
another thread calls VIDIOC_S_CTRL to modify V4L2_CID_HFLIP or
V4L2_CID_VFLIP, it locks the control handler and mutates ctrl->val.

Because this code reads imx681->vflip->val and imx681->hflip->val without
acquiring imx681->ctrl_handler.lock, this can lead to KCSAN warnings and
incorrect media bus code reporting due to stale reads.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261002082537.74084-1-lsa.uz@pm.me?part=2