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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <2d9bac728c5135fe3236f6f9fa55a3cb5739cffa.camel@ndufresne.ca>
Date: Wed, 16 Apr 2025 09:42:36 -0400
From: Nicolas Dufresne <nicolas@...fresne.ca>
To: Dikshita Agarwal <quic_dikshita@...cinc.com>, 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

Le mardi 15 avril 2025 à 10:01 +0530, Dikshita Agarwal a écrit :
> 
> 
> 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.

informative: Due to legacy behaviour of MFC and Coda, you should never
push a zero-length buffer without one of LAST or ERROR flag. It may be
interpreted as last by some userspace otherwise.

Can you eventually write some doc on the double state machine you have
? Having two state in a state machine makes reading the code quite
harder for reviewers.

Nicolas

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