Change #270350

Comments

aarch64: vp9lpf: Fix GCS violations
The aarch64 VP9 loopfilters actually violate aarch64 GCS
(Guarded Control Stack), even though we marked the code as GCS
compliant in 846746be4b8edd66be8be2c123b0072de2636e9d.

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 in
1f7ed8a78de1da743a359913ce05cc258a400b5d.

This issue wasn't observed if running checkasm in QEMU - therefore,
I thought all GCS issues had been fixed by
846746be4b8edd66be8be2c123b0072de2636e9d. (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.

Changed files

• libavcodec/aarch64/vp9lpf_16bpp_neon.S
• libavcodec/aarch64/vp9lpf_neon.S