From 39a24e8590849bd3d196b3fc2d8a64be5c742c9b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Per=20Lid=C3=A9n?= <pliden@openjdk.org>
Date: Fri, 15 Jun 2018 13:31:20 +0200
Subject: [PATCH] 8205020: ZGC: Apply workaround for buggy sem_post() in glibc
 < 2.21

Reviewed-by: stefank, eosterlund
---
 src/hotspot/share/gc/z/zMessagePort.inline.hpp | 11 +++++++++++
 src/hotspot/share/gc/z/zPageAllocator.cpp      | 11 +++++++++++
 2 files changed, 22 insertions(+)

diff --git a/src/hotspot/share/gc/z/zMessagePort.inline.hpp b/src/hotspot/share/gc/z/zMessagePort.inline.hpp
index dce6f22fa18..897a836ebc4 100644
--- a/src/hotspot/share/gc/z/zMessagePort.inline.hpp
+++ b/src/hotspot/share/gc/z/zMessagePort.inline.hpp
@@ -87,6 +87,17 @@ inline void ZMessagePort<T>::send_sync(T message) {
 
   // Wait for completion
   request.wait();
+
+  {
+    // Guard deletion of underlying semaphore. This is a workaround for a
+    // bug in sem_post() in glibc < 2.21, where it's not safe to destroy
+    // the semaphore immediately after returning from sem_wait(). The
+    // reason is that sem_post() can touch the semaphore after a waiting
+    // thread have returned from sem_wait(). To avoid this race we are
+    // forcing the waiting thread to acquire/release the lock held by the
+    // posting thread. https://sourceware.org/bugzilla/show_bug.cgi?id=12674
+    MonitorLockerEx ml(&_monitor, Monitor::_no_safepoint_check_flag);
+  }
 }
 
 template <typename T>
diff --git a/src/hotspot/share/gc/z/zPageAllocator.cpp b/src/hotspot/share/gc/z/zPageAllocator.cpp
index e77e409d3f7..2d2a7ebac07 100644
--- a/src/hotspot/share/gc/z/zPageAllocator.cpp
+++ b/src/hotspot/share/gc/z/zPageAllocator.cpp
@@ -337,6 +337,17 @@ ZPage* ZPageAllocator::alloc_page_blocking(uint8_t type, size_t size, ZAllocatio
       // Wait for allocation to complete or fail
       page = request.wait();
     } while (page == gc_marker);
+
+    {
+      // Guard deletion of underlying semaphore. This is a workaround for a
+      // bug in sem_post() in glibc < 2.21, where it's not safe to destroy
+      // the semaphore immediately after returning from sem_wait(). The
+      // reason is that sem_post() can touch the semaphore after a waiting
+      // thread have returned from sem_wait(). To avoid this race we are
+      // forcing the waiting thread to acquire/release the lock held by the
+      // posting thread. https://sourceware.org/bugzilla/show_bug.cgi?id=12674
+      ZLocker locker(&_lock);
+    }
   }
 
   return page;