runtime: always acquire M when acquiring locks by rank

Profiling of runtime-internal locks checks gp.m.locks to see if it's
safe to add a new record to the profile, but direct use of
acquireLockRank can change the list of the M's active lock ranks without
updating gp.m.locks to match. The runtime's internal rwmutex
implementation makes a point of calling acquirem/releasem when
manipulating the lock rank list, but the other user of acquireLockRank
(the GC's Gscan bit) relied on the GC's invariants to avoid deadlocks.

Codify the rwmutex approach by renaming acquireLockRank to
acquireLockRankAndM and having it include a call to aquirem. Do the same
for release.

Fixes #64706
Fixes #66004

Change-Id: Ib76eaa0cc1c45b64861d03345e17e1e843c19713
GitHub-Last-Rev: 160577bdb2bb2a4e869c6fd7e53e3be8fb819182
GitHub-Pull-Request: golang/go#66276
Reviewed-on: https://go-review.googlesource.com/c/go/+/571056
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Rhys Hiltner <rhys.hiltner@gmail.com>
Reviewed-by: Michael Pratt <mpratt@google.com>

1 files changed, 2 insertions, 5 deletions

diff --git a/src/runtime/rwmutex.go b/src/runtime/rwmutex.go
index 5833d59576..4f9585f98d 100644
--- a/src/runtime/rwmutex.go
+++ b/src/runtime/rwmutex.go
@@ -72,9 +72,7 @@ func (rw *rwmutex) rlock() {
 	// things blocking on the lock may consume all of the Ps and
 	// deadlock (issue #20903). Alternatively, we could drop the P
 	// while sleeping.
-	acquirem()
-
-	acquireLockRank(rw.readRank)
+	acquireLockRankAndM(rw.readRank)
 	lockWithRankMayAcquire(&rw.rLock, getLockRank(&rw.rLock))
 
 	if rw.readerCount.Add(1) < 0 {
@@ -116,8 +114,7 @@ func (rw *rwmutex) runlock() {
 			unlock(&rw.rLock)
 		}
 	}
-	releaseLockRank(rw.readRank)
-	releasem(getg().m)
+	releaseLockRankAndM(rw.readRank)
 }
 
 // lock locks rw for writing.