runtime: avoid overflow in mutex delay calculation

If cputicks is in the top quarter of the int64's range, adding two
values together will overflow and confuse the subsequent calculations,
leading to zero-duration contention events in the profile.

This fixes the TestRuntimeLockMetricsAndProfile failures on the
linux-s390x builder.

Change-Id: Icb814c39a8702379dfd71c06a53b2618e3589e07
Reviewed-on: https://go-review.googlesource.com/c/go/+/671115
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Rhys Hiltner <rhys.hiltner@gmail.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>

diff --git a/src/runtime/lock_spinbit.go b/src/runtime/lock_spinbit.go
index c2a6c76629c3922213fab98783a2a6ac90cd723d..f90698a4c943d4314828331ecd73cffd22bec79d 100644 (file)
--- a/src/runtime/lock_spinbit.go
+++ b/src/runtime/lock_spinbit.go
@@ -404,7 +404,7 @@ useStackLock:
                        n++
                        next := node.mWaitList.next.ptr()
                        if next == nil {
-                               cycles := endTicks - (head.mWaitList.startTicks+node.mWaitList.startTicks)/2
+                               cycles := ((endTicks - head.mWaitList.startTicks) + (endTicks - node.mWaitList.startTicks)) / 2
                                node.mWaitList.startTicks = endTicks
                                head.mWaitList.startTicks = endTicks
                                getg().m.mLockProfile.recordUnlock(cycles * int64(n))