linux-kernel - Re: [PATCH 01/20] media: iris: Skip destroying internal buffer if not dequeued

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: <30ebc1b7-5746-59a3-0155-7a7870544622@quicinc.com>
Date: Wed, 16 Apr 2025 22:10:12 +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>,
        <stable@...r.kernel.org>
Subject: Re: [PATCH 01/20] media: iris: Skip destroying internal buffer if not
 dequeued



On 4/16/2025 5:40 PM, Bryan O'Donoghue wrote:
> On 15/04/2025 05:58, Dikshita Agarwal wrote:
>> Although firmware makes sure that during session close, all buffers are
>> returned to driver and driver will release them but still we shouldn't rely
>> for this on firmware and should handle in driver.
>> Will fix this in next patch set.
> 
> Shouldn't we reset iris in this case ?
> 
Not required.
> i.e. its a breaking of the software contract to have failed to have
> returned a buffer by - close.
> 
> Its not enough to free the memory on the APSS side as the remote end could
> still assume ownership of a buffer... right ?
> 
Before close, Stop will be called to firmware and firmware will return all
the buffers to driver, which will transfer the ownership to driver, so no
issue with freeing these buffers in close.

Thanks,
Dikshita
> ---
> bod