[Git][ghc/ghc][wip/tsan/fixes-2] 18 commits: rts: Fix data race in CHECK_GC

Tue Jun 20 12:46:11 UTC 2023

Ben Gamari pushed to branch wip/tsan/fixes-2 at Glasgow Haskell Compiler / GHC

Commits:
8d96dbd0 by Ben Gamari at 2023-06-20T08:46:03-04:00
rts: Fix data race in CHECK_GC

- - - - -
fa2d7ece by Ben Gamari at 2023-06-20T08:46:03-04:00
base: use atomic write when updating timer manager

- - - - -
8f61117e by Ben Gamari at 2023-06-20T08:46:03-04:00
Use relaxed atomics to manipulate TSO status fields

- - - - -
b94b1578 by Ben Gamari at 2023-06-20T08:46:03-04:00
rts: Add necessary barriers when manipulating TSO owner

- - - - -
9b6e128f by Ben Gamari at 2023-06-20T08:46:03-04:00
rts: Fix synchronization on thread blocking state

- - - - -
cc4c72c6 by Ben Gamari at 2023-06-20T08:46:03-04:00
rts: Relaxed load MutVar info table

- - - - -
d8aaca20 by Ben Gamari at 2023-06-20T08:46:03-04:00
hadrian: More debug information

- - - - -
4d433891 by Ben Gamari at 2023-06-20T08:46:03-04:00
hadrian: More selective TSAN instrumentation

- - - - -
25811415 by Ben Gamari at 2023-06-20T08:46:03-04:00
codeGen/tsan: Rework handling of spilling

- - - - -
117cdf4a by Ben Gamari at 2023-06-20T08:46:03-04:00
codeGen: Ensure that TSAN is aware of writeArray# write barriers

- - - - -
c4e038ab by Ben Gamari at 2023-06-20T08:46:04-04:00
codeGen: Ensure that array reads have necessary barriers

This was the cause of #23541.

- - - - -
eada1f19 by Ben Gamari at 2023-06-20T08:46:04-04:00
Wordsmith TSAN Note

- - - - -
13f259b9 by Ben Gamari at 2023-06-20T08:46:04-04:00
codeGen: Use relaxed accesses in ticky bumping

- - - - -
dd9364aa by Ben Gamari at 2023-06-20T08:46:04-04:00
codeGen: Use relaxed-read in closureInfoPtr

- - - - -
b7aecf4d by Ben Gamari at 2023-06-20T08:46:04-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.

- - - - -
cb8ee074 by Ben Gamari at 2023-06-20T08:46:04-04:00
STM: Use acquire loads when possible

Full sequential consistency is not needed here.

- - - - -
5e918451 by Ubuntu at 2023-06-20T08:46:04-04:00
ghc-prim: Use C11 atomics

- - - - -
a382b0bf by Ubuntu at 2023-06-20T08:46:04-04:00
Run script

- - - - -

30 changed files:

- compiler/GHC/Cmm/Info.hs
- compiler/GHC/Cmm/ThreadSanitizer.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
- 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/RaiseAsync.c
- rts/STM.c
- rts/Schedule.c
- rts/StableName.c
- rts/StgMiscClosures.cmm
- rts/StgStartup.cmm
- rts/ThreadPaused.c
- rts/Threads.c
- rts/TraverseHeap.c
- rts/Updates.cmm
- rts/Updates.h
- rts/include/Cmm.h
- rts/include/rts/storage/ClosureMacros.h

The diff was not included because it is too large.

View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/e485e238e2ae4a9e9a9b6124613d1d43ad523725...a382b0bf1073f01799a5d482dca0ca81404e61da

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/e485e238e2ae4a9e9a9b6124613d1d43ad523725...a382b0bf1073f01799a5d482dca0ca81404e61da
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/20230620/bcaf6b2a/attachment.html>