linux-kernel - Re: [PATCH 05/20] 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 for Android: free password hash cracker in your pocket

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

Message-ID: <0241cee0-c121-3f30-57a2-f1d15b5e0839@quicinc.com>
Date: Tue, 15 Apr 2025 10:01:20 +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@...aro.org>,
        Neil Armstrong
	<neil.armstrong@...aro.org>,
        <linux-media@...r.kernel.org>, <linux-arm-msm@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <devicetree@...r.kernel.org>
Subject: Re: [PATCH 05/20] media: iris: Send V4L2_BUF_FLAG_ERROR for buffers
 with 0 filled length



On 4/11/2025 6:21 PM, Bryan O'Donoghue wrote:
> On 08/04/2025 16:54, 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.
> 
> Any buffer with a zero length must be flagged as LAST, else that buffer
> should be discarded.
> 
> Is this another bugfix ? Feels like one, processing redundant packets.
> 
>> 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 b75a01641d5d..91c5f04dd926 100644
>> --- a/drivers/media/platform/qcom/iris/iris_hfi_gen2_response.c
>> +++ b/drivers/media/platform/qcom/iris/iris_hfi_gen2_response.c
>> @@ -377,6 +377,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;
>> +    }
>> +
> 
> Is this hypothetical or does it happen in real life ?
Yes, it does. As part of flush, firmware returns the buffers with 0 filled
length but those shouldn't be marked as ERROR, same applies for buffer with
LAST flag.
This conditional check make sure the ERROR flag is associated with only
frames which are supposed to be dropped/discarded.

Thanks,
Dikshita
> 
>>       return 0;
>>   }
>>  
> 
> ---
> bod