[Git][ghc/ghc][wip/tsan/fix-races] 17 commits: Fix thunk update ordering

Ben Gamari (@bgamari) gitlab at gitlab.haskell.org
Wed Dec 13 20:52:50 UTC 2023 


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


Commits:
0f4a6a78 by Ben Gamari at 2023-12-13T15:51:57-05: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.

- - - - -
3deee773 by Ben Gamari at 2023-12-13T15:52:32-05:00
rts: Fix data race in threadPaused

This only affects an assertion in the debug RTS and only needs relaxed
ordering.

- - - - -
d9e4e569 by Ben Gamari at 2023-12-13T15:52:32-05: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.

- - - - -
2ffe9a3f by Ben Gamari at 2023-12-13T15:52:32-05:00
codeGen: Use relaxed accesses in ticky bumping

- - - - -
72bdc56e by Ben Gamari at 2023-12-13T15:52:32-05:00
rts: Fix data race in Interpreter's preemption check

- - - - -
e8698a79 by Ben Gamari at 2023-12-13T15:52:32-05:00
rts: Fix data race in threadStatus#

- - - - -
9a148b32 by Ben Gamari at 2023-12-13T15:52:32-05:00
base: use atomic write when updating timer manager

- - - - -
d86ea6c5 by Ben Gamari at 2023-12-13T15:52:32-05:00
Use relaxed atomics to manipulate TSO status fields

- - - - -
0fb2803e by Ben Gamari at 2023-12-13T15:52:32-05:00
rts: Add necessary barriers when manipulating TSO owner

- - - - -
4ef48b3b by Ben Gamari at 2023-12-13T15:52:32-05:00
rts: Fix synchronization on thread blocking state

- - - - -
521e76af by Ben Gamari at 2023-12-13T15:52:32-05:00
rts: Use relaxed ordering on dirty/clean info tables updates

When changing the dirty/clean state of a mutable object we needn't have
any particular ordering.

- - - - -
7180e2ee by Ben Gamari at 2023-12-13T15:52:33-05:00
codeGen: Use relaxed-read in closureInfoPtr

- - - - -
187d013f by Ben Gamari at 2023-12-13T15:52:33-05:00
STM: Use acquire loads when possible

Full sequential consistency is not needed here.

- - - - -
19a5b0ac by Ben Gamari at 2023-12-13T15:52:33-05:00
rts/Messages: Fix data race

- - - - -
bf0d9842 by Ben Gamari at 2023-12-13T15:52:33-05:00
rts/Prof: Fix data race

- - - - -
f5161b9e by Ben Gamari at 2023-12-13T15:52:33-05:00
rts: Use fence rather than redundant load

Previously we would use an atomic load to ensure acquire ordering.
However, we now have `ACQUIRE_FENCE_ON`, which allows us to express this
more directly.

- - - - -
fa8aca8e by Ben Gamari at 2023-12-13T15:52:33-05:00
rts: Fix data races in profiling timer

- - - - -


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/Ticky.hs
- compiler/GHC/StgToCmm/Utils.hs
- libraries/base/src/GHC/Event/Thread.hs
- 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
- rts/RaiseAsync.c
- rts/STM.c
- rts/Schedule.c
- rts/StableName.c
- rts/StgMiscClosures.cmm
- rts/StgStartup.cmm


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/99086ce046f00a2773a8ff02b93623f6f1f37d7c...fa8aca8e0304056d9a1139da0de450eb2fc6be68

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/99086ce046f00a2773a8ff02b93623f6f1f37d7c...fa8aca8e0304056d9a1139da0de450eb2fc6be68
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/20231213/b6fd189d/attachment.html>

More information about the ghc-commits mailing list