> On 14 Jul 2026, at 11:23 am, Anand Moon <[email protected]> wrote: > > Hi All, > > On Mon, 13 Jul 2026 at 17:38, Anand Moon <[email protected]> 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/[email protected]/ >> > > 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
