Memory ordering and thunk update
Ben Gamari
ben at smart-cactus.org
Sun Feb 10 00:01:51 UTC 2019
Hi Simon and Peter,
I just wanted to draw your attention to !337 [1], where I try to fix
#15994. While it's possible I have missed something, it looks to me like
there has been a bug lurking here for quite some time. In particular on
a weak memory model machine we do not place a write barrier between the
construction of the result of a thunk evaluation and making the results
visible to other cores via the indirection's indirectee field. This
essentially means that a thread looking at the indirectee may
essentially see uninitialized memory.
Specifically, updateWithIndirection is currently:
# Evaluation result p2 initialized by caller
...
((StgInd *)p1)->indirectee = p2;
write_barrier();
SET_INFO(p1, &stg_BLACKHOLE_info);
...
whereas I think this should rather be
# Evaluation result p2 initialized by caller
...
write_barrier();
((StgInd *)p1)->indirectee = p2;
SET_INFO(p1, &stg_BLACKHOLE_info);
...
I describe the reasoning for this in more detail in the Note added in
!337.
All-in-all, I'm rather surprised to find this bug. While we won't see
this issue manifest on x86_64 due to this architecture's memory model,
we have long supported ARM, PowerPC, and SPARC, all of which have
weakly-ordered execution modes. I can't find any relevant open tickets
from these platforms. The fact that this wasn't noticed on these
platforms makes me wonder whether I am just missing something.
Let me know what you think.
Cheers,
- Ben
[1] https://gitlab.haskell.org/ghc/ghc/merge_requests/337
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190209/6f6175fc/attachment.sig>
More information about the ghc-devs
mailing list