mirror of
https://git.ffmpeg.org/ffmpeg.git
synced 2026-06-16 04:32:47 +02:00
Martin Storsjö
d05786cf23
The aarch64 VP9 loopfilters actually violate aarch64 GCS (Guarded Control Stack), even though we marked the code as GCS compliant in846746be4b. This means that builds with GCS enabled, after that commit, will crash when decoding VP9, on future hardware (or current QEMU) that supports GCS. This also goes for ffmpeg version 8.1.1 where the GCS enabling was backported. This matches the fix that was done for hevcdsp in1f7ed8a78d. This issue wasn't observed if running checkasm in QEMU - therefore, I thought all GCS issues had been fixed by846746be4b. (If I would have tested the full "make fate" with QEMU, the issue would have appeared though.) However with the new checkasm, some of the GCS violations do appear even in checkasm. The reason is that the checkasm vp9 test intentionally craft input pixels that attempt to trigger all the individual separate cases in each input buffer (in randomize_loopfilter_buffers). This means that the checkasm tests actually never test or exercise the early exit cases, which are the ones that violate GCS. With the new checkasm, the call to "bench_new" always test running the code at least once, even if not benchmarking. As the input buffers weren't reinitialized between the test and "bench_new", the pixel differences now differ from the initial setup, so that the code now some times (often) would end up hitting the early exit cases. Ideally, the vp9 checkasm test would be repeated to cover all cases of input buffers that allow early exits, in addition to covering the case with all different cases in one block.