Revert 'Workaround TSan false positive about clear_hdr_marks/realloc race'

This reverts commit 20468dd131d82be7422aea3c7383ec9201452fce.

Because it is not a false positive.  And we are lying to the compiler
about the value not changing asynchronously, which is never good.
The proper solution could be use of atomic accesses (even unordered)
on the size field.

diff --git a/mallocx.c b/mallocx.c
index 5d42392fe73fd017929e7789b44d2a338969c487..d6e5fe1d11a813218564b5a5238f3454b704962b 100644 (file)
--- a/mallocx.c
+++ b/mallocx.c
@@ -78,18 +78,6 @@ GC_API GC_ATTR_MALLOC void * GC_CALL GC_generic_or_special_malloc(size_t lb,
     }
 }
 
-/* There could be a data race between this function (called from        */
-/* GC_realloc without any synchronization) and e.g. GC_clear_hdr_marks  */
-/* (invoked indirectly from GC_try_to_collect_inner) but it should be   */
-/* safe as long as the new size is not smaller than the old one.        */
-GC_ATTR_NO_SANITIZE_THREAD
-static void hb_sz_async_grow_within_hblk(hdr * hhdr, size_t sz)
-{
-    GC_ASSERT(hhdr->hb_sz <= sz
-              && sz <= ((hhdr->hb_sz + HBLKSIZE - 1) & ~HBLKMASK));
-    hhdr->hb_sz = sz;
-}
-
 /* Change the size of the block pointed to by p to contain at least   */
 /* lb bytes.  The object may be (and quite likely will be) moved.     */
 /* The kind (e.g. atomic) is the same as that of the old.             */
@@ -121,7 +109,7 @@ GC_API void * GC_CALL GC_realloc(void * p, size_t lb)
           word descr;
 
           sz = (sz+HBLKSIZE-1) & (~HBLKMASK);
-          hb_sz_async_grow_within_hblk(hhdr, sz);
+          hhdr -> hb_sz = sz;
           descr = GC_obj_kinds[obj_kind].ok_descriptor;
           if (GC_obj_kinds[obj_kind].ok_relocate_descr) descr += sz;
           hhdr -> hb_descr = descr;