[Git][ghc/ghc][wip/tsan/fix-races] 38 commits: rts: Introduce NO_WARN macro

Ben Gamari (@bgamari) gitlab at gitlab.haskell.org
Mon Jul 24 18:00:24 UTC 2023



Ben Gamari pushed to branch wip/tsan/fix-races at Glasgow Haskell Compiler / GHC


Commits:
df059575 by Ben Gamari at 2023-07-24T13:58:58-04:00
rts: Introduce NO_WARN macro

This allows fine-grained ignoring of warnings.

- - - - -
04b2fc72 by Ben Gamari at 2023-07-24T13:59:28-04:00
rts: Simplify atomicModifyMutVar2# implementation

Previously we would perform a redundant load in the non-threaded RTS in
atomicModifyMutVar2# implementation for the benefit of the non-moving
GC's write barrier. Eliminate this.

- - - - -
47cefc2c by Ben Gamari at 2023-07-24T13:59:45-04:00
codeGen/tsan: Rework handling of spilling

- - - - -
0908d5aa by Ben Gamari at 2023-07-24T13:59:46-04:00
hadrian: More debug information

- - - - -
a5447054 by Ben Gamari at 2023-07-24T13:59:46-04:00
Improve TSAN documentation

- - - - -
e4045a96 by Ben Gamari at 2023-07-24T13:59:46-04:00
hadrian: More selective TSAN instrumentation

- - - - -
c7e56f47 by Ben Gamari at 2023-07-24T13:59:58-04:00
rts: Fix data race in threadPaused

This only affects an assertion in the debug RTS, but it's a data race
nevertheless.

- - - - -
d8876441 by Ben Gamari at 2023-07-24T13:59:59-04:00
cmm: Introduce MO_RelaxedRead

In hand-written Cmm it can sometimes be necessary to atomically load
from memory deep within an expression (e.g. see the `CHECK_GC` macro).
This MachOp provides a convenient way to do so without breaking the
expression into multiple statements.

- - - - -
965e854f by Ben Gamari at 2023-07-24T13:59:59-04:00
rts: Silence spurious data races in ticky counters

Previously we would use non-atomic accesses when bumping ticky counters,
which would result in spurious data race reports from ThreadSanitizer
when the threaded RTS was in use.

- - - - -
322fec56 by Ben Gamari at 2023-07-24T13:59:59-04:00
rts: Fix data race in Interpreter's preemption check

- - - - -
5fd8e460 by Ben Gamari at 2023-07-24T13:59:59-04:00
rts: Fix data race in threadStatus#

- - - - -
f0c53940 by Ben Gamari at 2023-07-24T13:59:59-04:00
rts: Fix data race in CHECK_GC

- - - - -
6ff3e99f by Ben Gamari at 2023-07-24T13:59:59-04:00
base: use atomic write when updating timer manager

- - - - -
53fb087a by Ben Gamari at 2023-07-24T13:59:59-04:00
Use relaxed atomics to manipulate TSO status fields

- - - - -
a8683256 by Ben Gamari at 2023-07-24T13:59:59-04:00
rts: Add necessary barriers when manipulating TSO owner

- - - - -
e6c213ab by Ben Gamari at 2023-07-24T13:59:59-04:00
rts: Fix synchronization on thread blocking state

- - - - -
f35e4f70 by Ben Gamari at 2023-07-24T13:59:59-04:00
rts: Relaxed load MutVar info table

- - - - -
40441db9 by Ben Gamari at 2023-07-24T13:59:59-04:00
codeGen: Ensure that TSAN is aware of writeArray# write barriers

- - - - -
e54ae5d6 by Ben Gamari at 2023-07-24T13:59:59-04:00
codeGen: Ensure that array reads have necessary barriers

This was the cause of #23541.

- - - - -
8dae1b88 by Ben Gamari at 2023-07-24T13:59:59-04:00
Wordsmith TSAN Note

- - - - -
5f4429f5 by Ben Gamari at 2023-07-24T13:59:59-04:00
codeGen: Use relaxed accesses in ticky bumping

- - - - -
ac9392de by Ben Gamari at 2023-07-24T13:59:59-04:00
codeGen: Use relaxed-read in closureInfoPtr

- - - - -
46b5f5d5 by Ben Gamari at 2023-07-24T13:59:59-04:00
Fix thunk update ordering

Previously we attempted to ensure soundness of concurrent thunk update
by synchronizing on the access of the thunk's info table pointer field.
This was believed to be sufficient since the indirectee (which may
expose a closure allocated by another core) would not be examined
until the info table pointer update is complete.

However, it turns out that this can result in data races in the presence
of multiple threads racing a update a single thunk. For instance,
consider this interleaving under the old scheme:

            Thread A                             Thread B
            ---------                            ---------
    t=0     Enter t
      1     Push update frame
      2     Begin evaluation

      4     Pause thread
      5     t.indirectee=tso
      6     Release t.info=BLACKHOLE

      7     ... (e.g. GC)

      8     Resume thread
      9     Finish evaluation
      10    Relaxed t.indirectee=x

      11                                         Load t.info
      12                                         Acquire fence
      13                                         Inspect t.indirectee

      14    Release t.info=BLACKHOLE

Here Thread A enters thunk `t` but is soon paused, resulting in `t`
being lazily blackholed at t=6. Then, at t=10 Thread A finishes
evaluation and updates `t.indirectee` with a relaxed store.

Meanwhile, Thread B enters the blackhole. Under the old scheme this
would introduce an acquire-fence but this would only synchronize with
Thread A at t=6. Consequently, the result of the evaluation, `x`, is not
visible to Thread B, introducing a data race.

We fix this by treating the `indirectee` field as we do all other
mutable fields. This means we must always access this field with
acquire-loads and release-stores.

See #23185.

- - - - -
52006729 by Ben Gamari at 2023-07-24T13:59:59-04:00
STM: Use acquire loads when possible

Full sequential consistency is not needed here.

- - - - -
0ee0f2df by Ubuntu at 2023-07-24T13:59:59-04:00
ghc-prim: Use C11 atomics

- - - - -
539e2a5b by Ubuntu at 2023-07-24T13:59:59-04:00
Run script

- - - - -
1cd4cefb by Ben Gamari at 2023-07-24T13:59:59-04:00
hadrian: Ensure that way-flags are passed to CC

Previously the way-specific compilation flags (e.g. `-DDEBUG`,
`-DTHREADED_RTS`) would not be passed to the CC invocations. This meant
that C dependency files would not correctly reflect
dependencies predicated on the way, resulting in the rather
painful #23554.

Closes #23554.

- - - - -
945355b5 by Ben Gamari at 2023-07-24T13:59:59-04:00
rts/Interpreter: Fix data race

- - - - -
a071ba09 by Ben Gamari at 2023-07-24T13:59:59-04:00
rts/Messages: Fix data race

- - - - -
f6c3da63 by Ben Gamari at 2023-07-24T13:59:59-04:00
rts/Prof: Fix data race

- - - - -
c0df6355 by Ben Gamari at 2023-07-24T13:59:59-04:00
rts: Fix various data races

- - - - -
e272d834 by Ben Gamari at 2023-07-24T13:59:59-04:00
rts: Use fence rather than redundant load

- - - - -
15c7eeab by Ben Gamari at 2023-07-24T13:59:59-04:00
codeGen: More precise barriers for eager blackholing

- - - - -
6e89673e by Ben Gamari at 2023-07-24T13:59:59-04:00
Tighten up thunk update barriers

- - - - -
c4dd2992 by Ben Gamari at 2023-07-24T13:59:59-04:00
rts: Ensure that TSANUtils.h is included in Stg.h

- - - - -
94ef84b6 by Ben Gamari at 2023-07-24T13:59:59-04:00
rts: Fix unsupported fence warnings with TSAN

- - - - -
1a46a250 by Ben Gamari at 2023-07-24T13:59:59-04:00
rts/RaiseAsync: Drop redundant release fence

- - - - -
690c0791 by Ben Gamari at 2023-07-24T13:59:59-04:00
rts: Fixes profiling timer races

- - - - -


30 changed files:

- compiler/GHC/Cmm/Expr.hs
- compiler/GHC/Cmm/Info.hs
- compiler/GHC/Cmm/MachOp.hs
- compiler/GHC/Cmm/Parser.y
- compiler/GHC/Cmm/ThreadSanitizer.hs
- compiler/GHC/CmmToAsm/AArch64/CodeGen.hs
- compiler/GHC/CmmToAsm/PPC/CodeGen.hs
- compiler/GHC/CmmToAsm/Wasm/FromCmm.hs
- compiler/GHC/CmmToAsm/X86/CodeGen.hs
- compiler/GHC/CmmToC.hs
- compiler/GHC/CmmToLlvm/CodeGen.hs
- compiler/GHC/StgToCmm/Bind.hs
- compiler/GHC/StgToCmm/Prim.hs
- compiler/GHC/StgToCmm/Ticky.hs
- compiler/GHC/StgToCmm/Utils.hs
- hadrian/src/Flavour.hs
- hadrian/src/Settings/Builders/Common.hs
- hadrian/src/Settings/Builders/Ghc.hs
- hadrian/src/Settings/Packages.hs
- libraries/base/GHC/Event/Thread.hs
- libraries/ghc-prim/cbits/atomic.c
- rts/Apply.cmm
- rts/Compact.cmm
- rts/Exception.cmm
- rts/Heap.c
- rts/HeapStackCheck.cmm
- rts/Interpreter.c
- rts/Messages.c
- rts/PrimOps.cmm
- rts/Proftimer.c


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/08db5433e73a586c8db7a7feff12a5dc370628d2...690c0791fd85de6049dc845a10f2231de4a71661

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/08db5433e73a586c8db7a7feff12a5dc370628d2...690c0791fd85de6049dc845a10f2231de4a71661
You're receiving this email because of your account on gitlab.haskell.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-commits/attachments/20230724/a656bebd/attachment-0001.html>


More information about the ghc-commits mailing list