From 2aa4a82499d4becd2284cdb482213d541b8804dd Mon Sep 17 00:00:00 2001 From: Daniel Baumann Date: Sun, 28 Apr 2024 16:29:10 +0200 Subject: Adding upstream version 86.0.1. Signed-off-by: Daniel Baumann --- third_party/rust/tokio-0.1.11/ci/tsan | 33 +++++++++++++++++++++++++++++++++ 1 file changed, 33 insertions(+) create mode 100644 third_party/rust/tokio-0.1.11/ci/tsan (limited to 'third_party/rust/tokio-0.1.11/ci') diff --git a/third_party/rust/tokio-0.1.11/ci/tsan b/third_party/rust/tokio-0.1.11/ci/tsan new file mode 100644 index 0000000000..65d65eff24 --- /dev/null +++ b/third_party/rust/tokio-0.1.11/ci/tsan @@ -0,0 +1,33 @@ +# TSAN suppressions file for Tokio + +# TSAN does not understand fences and `Arc::drop` is implemented using a fence. +# This causes many false positives. +race:Arc*drop +race:Weak*drop + +# `std` mpsc is not used in any Tokio code base. This race is triggered by some +# rust runtime logic. +race:std*mpsc_queue + +# Probably more fences in std. +race:__call_tls_dtors + +# The epoch-based GC uses fences. +race:crossbeam_epoch + +# 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 + +# This filters out expected data race in the Treiber stack implementations. +# Treiber stacks are inherently racy. The pop operation will attempt to access +# the "next" pointer on the node it is attempting to pop. However, at this +# point it has not gained ownership of the node and another thread might beat +# it and take ownership of the node first (touching the next pointer). The +# original pop operation will fail due to the ABA guard, but tsan still picks +# up the access on the next pointer. +race:Backup::next_sleeper +race:Backup::set_next_sleeper +race:WorkerEntry::set_next_sleeper -- cgit v1.2.3