linux-kernel - Re: [PATCH v3 13/23] media: iris: Send V4L2_BUF_FLAG

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: <a21e2c36-90a9-0259-2619-25fc47b34ab5@quicinc.com>
Date: Fri, 2 May 2025 19:52:56 +0530
From: Dikshita Agarwal <quic_dikshita@...cinc.com>
To: Bryan O'Donoghue <bryan.odonoghue@...aro.org>,
        Vikash Garodia
	<quic_vgarodia@...cinc.com>,
        Abhinav Kumar <quic_abhinavk@...cinc.com>,
        "Mauro Carvalho Chehab" <mchehab@...nel.org>,
        Stefan Schmidt
	<stefan.schmidt@...aro.org>,
        Hans Verkuil <hverkuil@...all.nl>,
        "Bjorn
 Andersson" <andersson@...nel.org>,
        Konrad Dybcio <konradybcio@...nel.org>,
        "Rob Herring" <robh@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        "Conor Dooley" <conor+dt@...nel.org>
CC: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>,
        Neil Armstrong
	<neil.armstrong@...aro.org>,
        Nicolas Dufresne
	<nicolas.dufresne@...labora.com>,
        <linux-media@...r.kernel.org>, <linux-arm-msm@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <20250417-topic-sm8x50-iris-v10-v7-0-f020cb1d0e98@...aro.org>,
        <20250424-qcs8300_iris-v5-0-f118f505c300@...cinc.com>
Subject: Re: [PATCH v3 13/23] media: iris: Send V4L2_BUF_FLAG_ERROR for
 buffers with 0 filled length



On 5/2/2025 6:19 PM, Bryan O'Donoghue wrote:
> On 01/05/2025 20:13, Dikshita Agarwal wrote:
>> Firmware sends buffers with 0 filled length which needs to be dropped,
>> to achieve the same, add V4L2_BUF_FLAG_ERROR to such buffers.
>> Also make sure:
>> - These 0 length buffers are not returned as result of flush.
>> - Its not a buffer with LAST flag enabled which will also have 0 filled
>>    length.
>>
>> Acked-by: Vikash Garodia <quic_vgarodia@...cinc.com>
>> Signed-off-by: Dikshita Agarwal <quic_dikshita@...cinc.com>
>> ---
>>   drivers/media/platform/qcom/iris/iris_hfi_gen2_response.c | 6 ++++++
>>   1 file changed, 6 insertions(+)
>>
>> diff --git a/drivers/media/platform/qcom/iris/iris_hfi_gen2_response.c
>> b/drivers/media/platform/qcom/iris/iris_hfi_gen2_response.c
>> index 4488540d1d41..3bb326843a7b 100644
>> --- a/drivers/media/platform/qcom/iris/iris_hfi_gen2_response.c
>> +++ b/drivers/media/platform/qcom/iris/iris_hfi_gen2_response.c
>> @@ -378,6 +378,12 @@ static int iris_hfi_gen2_handle_output_buffer(struct
>> iris_inst *inst,
>>         buf->flags = iris_hfi_gen2_get_driver_buffer_flags(inst,
>> hfi_buffer->flags);
>>   +    if (!buf->data_size && inst->state == IRIS_INST_STREAMING &&
>> +        !(hfi_buffer->flags & HFI_BUF_FW_FLAG_LAST) &&
>> +        !(inst->sub_state & IRIS_INST_SUB_DRC)) {
>> +        buf->flags |= V4L2_BUF_FLAG_ERROR;
>> +    }
>> +
>>       return 0;
>>   }
>>  
> 
> This is a pretty complex conjunctive clause.
> 
> Is it possible for say 1/3 of these logical criteria to be false ?
> 
> i.e. if you get to:
> 
> 1. buf->data_size && inst->state == IRIS_INST_STREAMING
This makes sure that the 0 length buffers are not returned as response to
flush.
> 2. !(hfi_buffer->flags & HFI_BUF_FW_FLAG_LAST)
This makes sure that we don't mark the buffer with last flag as error since
this will be also be a zero length buffer but a valid one.
> 
> is it possible to get to
> 
> 3. !(inst->sub_state & IRIS_INST_SUB_DRC)
I can remove this condition as first one captures the essence of this one.

Thanks,
Dikshita
> 
> ?
> 
> This also feels like a bugfix ?
> 
> ---
> bod