[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <3teih4ch3qze5xdt4at2snv4ln5ebffhdc4f7bclbqxr3dhoiu@kwjnitey74uk>
Date: Mon, 6 Jan 2025 22:24:43 +0900
From: Sergey Senozhatsky <senozhatsky@...omium.org>
To: Hans Verkuil <hverkuil@...all.nl>
Cc: Sergey Senozhatsky <senozhatsky@...omium.org>,
Stanimir Varbanov <stanimir.k.varbanov@...il.com>, Vikash Garodia <quic_vgarodia@...cinc.com>,
Bryan O'Donoghue <bryan.odonoghue@...aro.org>, Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
linux-media@...r.kernel.org, linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
stable@...r.kernel.org, Nathan Hebert <nhebert@...gle.com>
Subject: Re: [PATCHv3 1/2] media: venus: destroy hfi session after m2m_ctx
release
Hi Hans,
On (25/01/06 14:15), Hans Verkuil wrote:
> Hi Sergey,
>
> On 24/12/2024 08:24, Sergey Senozhatsky wrote:
> > This partially reverts commit that made hfi_session_destroy()
> > the first step of vdec/venc close(). The reason being is a
> > regression report when, supposedly, encode/decoder is closed
> > with still active streaming (no ->stop_streaming() call before
> > close()) and pending pkts, so isr_thread cannot find instance
> > and fails to process those pending pkts. This was the idea
> > behind the original patch - make it impossible to use instance
> > under destruction, because this is racy, but apparently there
> > are uses cases that depend on that unsafe pattern. Return to
> > the old (unsafe) behaviour for the time being (until a better
> > fix is found).
> >
> > Fixes: 45b1a1b348ec1 ("media: venus: sync with threaded IRQ during inst destruction")
> > Cc: stable@...r.kernel.org
> > Reported-by: Nathan Hebert <nhebert@...gle.com>
>
> Do you have a link to Nathan's report so I can add a 'Closes' tag
> afterwards?
No public link is available as the report was internal.
Powered by blists - more mailing lists