linux-kernel - Re: [PATCH v3 17/29] media: iris: implement query_cap, query_ctrl and query

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <8f156cc8-d8f8-4caf-8431-4a549f41ac0f@linaro.org>
Date: Tue, 24 Sep 2024 15:49:07 +0100
From: Bryan O'Donoghue <bryan.odonoghue@...aro.org>
To: quic_dikshita@...cinc.com, Vikash Garodia <quic_vgarodia@...cinc.com>,
 Abhinav Kumar <quic_abhinavk@...cinc.com>,
 Mauro Carvalho Chehab <mchehab@...nel.org>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Philipp Zabel <p.zabel@...gutronix.de>
Cc: linux-media@...r.kernel.org, linux-arm-msm@...r.kernel.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
 Vedang Nagar <quic_vnagar@...cinc.com>
Subject: Re: [PATCH v3 17/29] media: iris: implement query_cap, query_ctrl and
 query_menu ioctls

On 27/08/2024 11:05, Dikshita Agarwal via B4 Relay wrote:
> From: Vedang Nagar <quic_vnagar@...cinc.com>
> 
> Implement query_cap, query_ctrl and query_menu ioctls in the
> driver with necessary hooks.
> 
> Signed-off-by: Vedang Nagar <quic_vnagar@...cinc.com>
> Signed-off-by: Dikshita Agarwal <quic_dikshita@...cinc.com>
> ---
>   drivers/media/platform/qcom/iris/iris_vidc.c | 89 ++++++++++++++++++++++++++++
>   1 file changed, 89 insertions(+)
> 
> diff --git a/drivers/media/platform/qcom/iris/iris_vidc.c b/drivers/media/platform/qcom/iris/iris_vidc.c
> index 7d5da30cb1d1..1dd612b7cec5 100644
> --- a/drivers/media/platform/qcom/iris/iris_vidc.c
> +++ b/drivers/media/platform/qcom/iris/iris_vidc.c
> @@ -362,6 +362,92 @@ static int iris_enum_framesizes(struct file *filp, void *fh,
>   	return ret;
>   }
>   
> +static int iris_querycap(struct file *filp, void *fh, struct v4l2_capability *cap)
> +{
> +	struct iris_inst *inst;
> +	int ret = 0;
> +
> +	inst = iris_get_inst(filp, fh);
> +	if (!inst)
> +		return -EINVAL;
> +
> +	mutex_lock(&inst->lock);
> +	strscpy(cap->driver, IRIS_DRV_NAME, sizeof(cap->driver));
> +	strscpy(cap->bus_info, IRIS_BUS_NAME, sizeof(cap->bus_info));
> +	memset(cap->reserved, 0, sizeof(cap->reserved));
> +	strscpy(cap->card, "iris_decoder", sizeof(cap->card));
> +	mutex_unlock(&inst->lock);

Locking is a good thing but, this seems very rote.

What's being protected here ?

Please take a critical - no pun intended - look at your locking strategy 
here.

I mentioned previously taking a core lock and releasing it with a level 
of granularity that didn't make a ton of sense to me, here's another 
example of locking for locking's sake.

Please go through your code, look at your locks with a critical eye and 
say "what's this for, why are doing this, what is the lock supposed to 
guarantee here".

I appreciate that can be difficult with a progressive patchset so 
recommend jumping in at the end and doing that analysis.

---
bod