From 962576d18e4a3d9da74fa5e60bd8988cc372dca4 Mon Sep 17 00:00:00 2001 From: Adam Gutglick Date: Wed, 17 Jun 2026 13:03:22 +0100 Subject: [PATCH] Suppress TSAN false positives in crossbeam crate due to use of memory fences Signed-off-by: Adam Gutglick --- vortex-ffi/tsan_suppressions.txt | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/vortex-ffi/tsan_suppressions.txt b/vortex-ffi/tsan_suppressions.txt index ee8ac6e926d..6a2b65e351e 100644 --- a/vortex-ffi/tsan_suppressions.txt +++ b/vortex-ffi/tsan_suppressions.txt @@ -6,3 +6,23 @@ # where ordering is correct but uses an explicit fence and not relaxed load race:oneshot-*/src/channel.rs race:oneshot-*/src/lib.rs + +# https://github.com/google/sanitizers/issues/1415 +# crossbeam-epoch's epoch-based reclamation synchronizes through SeqCst fences, +# which TSan does not fully model. Its process-global collector frees a retired +# bag/node on one thread while another thread pops from the same GC queue, both +# inside `Global::collect`; the epoch protocol makes this safe but TSan reports a +# benign race. Surfaced through moka's cache (the vortex-file MultiFileSession +# footer cache) when one session's cache is dropped while another session's cache +# is queried on a parallel thread. +race:crossbeam_epoch*collect + +# Taken from crossbeam's CI - https://github.com/crossbeam-rs/crossbeam/blob/05f9478b333ead58c0bf8e5a37d9ef9bd3b5bf17/ci/tsan#L1 +# Push and steal operations in crossbeam-deque may cause data races, but such +# data races are safe. If a data race happens, the value read by `steal` is +# forgotten and the steal operation is then retried. +race:crossbeam_deque*push +race:crossbeam_deque*steal + +# Non-lock-free AtomicCell uses SeqLock which uses fences. +race:crossbeam_utils::atomic::atomic_cell::atomic_compare_exchange_weak