]> git.sesse.net Git - ffmpeg/commit
avcodec/fft_template, fft_init_table: Make ff_fft_init() thread-safe
authorAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
Wed, 18 Nov 2020 20:38:45 +0000 (21:38 +0100)
committerAndreas Rheinhardt <andreas.rheinhardt@gmail.com>
Tue, 24 Nov 2020 10:35:03 +0000 (11:35 +0100)
commitb9c1ab89078d862e0146c9d7ed277addd770e3a3
treec86dced567b59082c051b463dbad9a1385abd4be
parent5c45f7e15603c43e04747e5385d521ab6c8720ca
avcodec/fft_template, fft_init_table: Make ff_fft_init() thread-safe

Commit 1af615683e4a1a858407afbaa2fd686842da7e49 put initializing
the ff_fft_offsets_lut (which is typically used if FFT_FIXED_32)
behind an ff_thread_once() to make ff_fft_init() thread-safe; yet
there is a second place where said table may be initialized which
is not guarded by this AVOnce: ff_fft_init_mips(). MIPS uses this LUT
even for ordinary floating point FFTs, so that ff_fft_init() is not
thread-safe (on MIPS) for both 32bit fixed-point as well as
floating-point FFTs; e.g. ff_mdct_init() inherits this flaw and
therefore initializing e.g. the AAC decoders is not thread-safe (on
MIPS) despite them having FF_CODEC_CAP_INIT_CLEANUP set.

This commit fixes this by moving the AVOnce to fft_init_table.c and
using it to guard all initializations of ff_fft_offsets_lut.

(It is not that bad in practice, because every entry of
ff_fft_offsets_lut is never read during initialization and is only once
ever written to (namely to its final value); but even these are
conflicting actions which are (by definition) data races and lead to
undefined behaviour.)

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
libavcodec/fft_init_table.c
libavcodec/fft_table.h
libavcodec/fft_template.c
libavcodec/mips/fft_mips.c