)]}'
{
  "commit": "d7df7f4fa01f1b445d835fc908c54448a63c68fb",
  "tree": "726cb479c96cc278e16a5718f8c92974ed9811e3",
  "parents": [
    "a95136a88cb8a51ede3ec2cdca4cfa3962dcfacd"
  ],
  "author": {
    "name": "Michael Pratt",
    "email": "mpratt@google.com",
    "time": "Wed Dec 13 15:07:28 2023 -0500"
  },
  "committer": {
    "name": "Cherry Mui",
    "email": "cherryyz@google.com",
    "time": "Thu Jan 25 17:20:11 2024 +0000"
  },
  "message": "[release-branch.go1.20] runtime: properly model rwmutex in lock ranking\n\n(This cherry-pick combines CL 549536 and the follow-up fix CL 555055.)\n\nCurrently, lock ranking doesn\u0027t really try to model rwmutex. It records\nthe internal locks rLock and wLock, but in a subpar fashion:\n\n1. wLock is held from lock to unlock, so it works OK, but it conflates\n   write locks of all rwmutexes as rwmutexW, rather than allowing\n   different rwmutexes to have different rankings.\n2. rLock is an internal implementation detail that is only taken when\n   there is contention in rlock. As as result, the reader lock path is\n   almost never checked.\n\nAdd proper modeling. rwmutexR and rwmutexW remain as the ranks of the\ninternal locks, which have their own ordering. The new init method is\npassed the ranks of the higher level lock that this represents, just\nlike lockInit for mutex.\n\nexecW ordered before MALLOC captures the case from #64722. i.e., there\ncan be allocation between BeforeFork and AfterFork.\n\nFor #64722.\nFixes #64760.\n\n------\n\nruntime: replace rwmutexR/W with per-rwmutex lock rank\n\nCL 549536 intended to decouple the internal implementation of rwmutex\nfrom the semantic meaning of an rwmutex read/write lock in the static\nlock ranking.\n\nUnfortunately, it was not thought through well enough. The internals\nwere represented with the rwmutexR and rwmutexW lock ranks. The idea was\nthat the internal lock ranks need not model the higher-level ordering,\nsince those have separate rankings. That is incorrect; rwmutexW is held\nfor the duration of a write lock, so it must be ranked before any lock\ntaken while any write lock is held, which is precisely what we were\ntrying to avoid.\n\nThis is visible in violations like:\n\n        0 : execW 11 0x0\n        1 : rwmutexW 51 0x111d9c8\n        2 : fin 30 0x111d3a0\n        fatal error: lock ordering problem\n\nexecW \u003c fin is modeled, but rwmutexW \u003c fin is missing.\n\nFix this by eliminating the rwmutexR/W lock ranks shared across\ndifferent types of rwmutex. Instead require users to define an\nadditional \"internal\" lock rank to represent the implementation details\nof rwmutex.rLock. We can avoid an additional \"internal\" lock rank for\nrwmutex.wLock because the existing writeRank has the same semantics for\nsemantic and internal locking. i.e., writeRank is held for the duration\nof a write lock, which is exactly how rwmutex.wLock is used, so we can\nuse writeRank directly on wLock.\n\nFor #64722.\n\nCq-Include-Trybots: luci.golang.try:go1.20-linux-amd64-staticlockranking\nChange-Id: I23335b28faa42fb04f1bc9da02fdf54d1616cd28\nReviewed-on: https://go-review.googlesource.com/c/go/+/549536\nReviewed-by: Michael Knyszek \u003cmknyszek@google.com\u003e\nLUCI-TryBot-Result: Go LUCI \u003cgolang-scoped@luci-project-accounts.iam.gserviceaccount.com\u003e\n(cherry picked from commit 9b4b3e5acca2dabe107fa2c3ed963097d78a4562)\n(cherry picked from commit dcbe77246922fe7ef41f07df228f47a37803f360)\nReviewed-on: https://go-review.googlesource.com/c/go/+/554995\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "2290f7c728512df2979daea9521343a291280286",
      "old_mode": 33188,
      "old_path": "src/runtime/export_test.go",
      "new_id": "3d8d6d312b25679ddb53e251ba1f6761e031aff3",
      "new_mode": 33188,
      "new_path": "src/runtime/export_test.go"
    },
    {
      "type": "modify",
      "old_id": "284a61e3365c9ebb30994fbe06768aaab1877070",
      "old_mode": 33188,
      "old_path": "src/runtime/lockrank.go",
      "new_id": "e51d7a0a471f8bd9ae7128200671f813adf9b214",
      "new_mode": 33188,
      "new_path": "src/runtime/lockrank.go"
    },
    {
      "type": "modify",
      "old_id": "bc15e57dd4c9fae63a2fcc073261555121002cea",
      "old_mode": 33188,
      "old_path": "src/runtime/mklockrank.go",
      "new_id": "ef2f07d68a20eb2bce592b7a95a4e766a7a14d88",
      "new_mode": 33188,
      "new_path": "src/runtime/mklockrank.go"
    },
    {
      "type": "modify",
      "old_id": "96908fc6a5e2cd9f39f41b668a2b905d32f40e4c",
      "old_mode": 33188,
      "old_path": "src/runtime/proc.go",
      "new_id": "c1e45a415eb050fc856b816758f093020367eb63",
      "new_mode": 33188,
      "new_path": "src/runtime/proc.go"
    },
    {
      "type": "modify",
      "old_id": "ede3d13599c4d59817a9c830ef1f434ea2e9283d",
      "old_mode": 33188,
      "old_path": "src/runtime/rwmutex.go",
      "new_id": "34d8f675c1798525af797e7b4ad2c465b01e7cfc",
      "new_mode": 33188,
      "new_path": "src/runtime/rwmutex.go"
    },
    {
      "type": "modify",
      "old_id": "ddb16aead4382b615f16dbac8045fc947320220e",
      "old_mode": 33188,
      "old_path": "src/runtime/rwmutex_test.go",
      "new_id": "bdeb9c4901ddfc61162a4e6f5d8e40f6b292dbeb",
      "new_mode": 33188,
      "new_path": "src/runtime/rwmutex_test.go"
    }
  ]
}