Re: [PATCH v7 00/19] media: meson: vdec: Fix lifecycles, race conditions, and stability bugs

[Christian Hewitt <christianshewitt@gmail.com>]

> On 14 Jul 2026, at 11:23 am, Anand Moon <linux.amoon@gmail.com> wrote:
> 
> Hi All,
> 
> On Mon, 13 Jul 2026 at 17:38, Anand Moon <linux.amoon@gmail.com> wrote:
>> 
>> This patch series addresses a collection of critical race conditions,
>> memory leaks, use-after-free bugs, and resource management issues
>> within the Amlogic Meson video decoder (meson-vdec) driver and
>> associated components.
>> 
>> The primary focus is tightening session lifecycles, safely synchronising
>> the V4L2 m2m framework callbacks, hardening work queue operations
>> (esparser_queue_work), and correcting buffer validations to prevent
>> stability issues like KASAN out-of-bounds errors or stream-on timeouts.
>> 
>> Summary of Changes:
>> * Race Conditions & Synchronisation: Fixes multi-threading and
>>  execution races across stream-on, stream-off, job abort, and
>>  teardown pathways.
>> * Memory Lifecycle: Eliminates memory leaks and use-after-free
>>  vulnerabilities by safely pinning, canceling, and sequencing
>>  device removals.
>> * VP9 & Buffer Hardening: Addresses payload handling bugs in the ES
>>  parser, properly tracks ongoing buffers via atomic counters, and
>>  prevents invalid memory writes.
>> * Platform/DMA Adjustments: Adjusts DMA segment configurations,
>>  canvas handling, and buffer sizes to match modern hardware demands.
>> 
>> Note on an outstanding issue:
>> An execution deadlock occurs in the driver workqueue path during high
>> stress or long playback sessions. This stall is triggered when the
>> Amlogic hardware internal video FIFO buffer becomes completely full.
>> When esparser_queue_all_src runs, the capacity validation check is
>> tripped due to a design limitation in how buffer exhaustion is handled.
>> This blocks progress and leaves the workqueue worker waiting indefinitely
>> on a core mutex lock.
>> 
>> The resulting hung task call trace shows the worker thread blocking
>> on the internal lock:
>> 
>> Workqueue: events esparser_queue_all_src [meson_vdec]
>> ...
>> __mutex_lock
>> mutex_lock_nested
>> esparser_queue_all_src
>> 
>> I have tried to address this issue, but the underlying deadlock persists
>> under extreme conditions.
>> 
>> Any feedback on this new appock is welcome.
>> 
>> Testing was done using v4l2-compliance and active decoding pipelines
>> on Meson platforms (like Hardkernel ODROID-N2+ and ODROID-C4) SBCs.
>> 
>> The v4l2-compliance tests passed successfully via:
>> $ v4l2-compliance -s -v -d /dev/video0
>> 
>> Pipelines were validated using the following GStreamer script.
>> 
>> [1] https://gist.github.com/moonlinux/08295ba1f17ce7155550773f2d2cb6e5
>> 
>> Previous changes:
>> v6: https://lore.kernel.org/all/20260530094326.11892-2-linux.amoon@gmail.com/
>> 
> 
> I will review Sashiko's feedback. I will look into these suggestions and
> work on incorporating them to improve the code quality

Hello Anand,

I’ve picked this entire series into a LibreELEC image using Kodi 22 and
ffmpeg 8.1 (using the RPi source that improves v4l2_m2m behaviour) on a
7.2-rc3 kernel and run some tests on a GXBB/S905 board.

Without this series H264 plays and seeks well and the unmerged H265 codec
also plays well and seeks well but with minor artefacts (something that I
need to look into). The experience is not perfect (this driver has a few
flaws) but it’s consistent with the ‘usable’ behaviour of the driver in
the last 1-2 years.

With this series H264 plays but seek seems to hang everything with no logged
errors anywhere. H265 results in a black screen and again everything’s hung.

It’s possible that kernel changes need to be balanced with userspace? Can
you please share details of how you have been testing things (and on what
hardware)? - I will attempt to replicate and poke smaller portions of the
series to see if I can isolate which bits are problematic to the otherwise
usable current experience.

Christian




_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic