Did miri spot a concurrency bug taking RwLockWriteGuard?

[workingjubilee]

We had this happen in CI:

  test sync::reentrant_lock::tests::trylock_works ... ok
  error: Undefined Behavior: trying to retag from <46610762> for SharedReadWrite permission at alloc15134060[0x0], but that tag does not exist in the borrow stack for this location
  Error:    --> /checkout/library/core/src/ptr/non_null.rs:402:18
      |
  402 |         unsafe { &*self.as_ptr().cast_const() }
      |                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      |                  |
      |                  trying to retag from <46610762> for SharedReadWrite permission at alloc15134060[0x0], but that tag does not exist in the borrow stack for this location
      |                  this error occurs as part of retag at alloc15134060[0x0..0x28]
      |
      = help: this indicates a potential bug in the program: it performed an invalid operation, but the Stacked Borrows rules it violated are still experimental
      = help: see https://github.com/rust-lang/unsafe-code-guidelines/blob/master/wip/stacked-borrows.md for further information
  help: <46610762> was created by a SharedReadWrite retag at offsets [0x0..0x21]
     --> /checkout/library/core/src/ptr/mod.rs:789:5
      |
  789 |     r
      |     ^
  help: <46610762> was later invalidated at offsets [0x8..0x10] by a write access
     --> library/std/src/sys/sync/rwlock/queue.rs:345:17
      |
  345 |                 node.prev = AtomicLink::new(None);
      |                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      = note: BACKTRACE (of the first span) on thread `unnamed-776`:
      = note: inside `core::ptr::NonNull::<sys::sync::rwlock::queue::Node>::as_ref::<'_>` at /checkout/library/core/src/ptr/non_null.rs:402:18: 402:46
  note: inside `sys::sync::rwlock::queue::add_backlinks_and_find_tail`
     --> library/std/src/sys/sync/rwlock/queue.rs:255:34
      |
  255 |         let c = unsafe { current.as_ref() };
      |                                  ^^^^^^^^
  note: inside `sys::sync::rwlock::queue::RwLock::unlock_queue`
     --> library/std/src/sys/sync/rwlock/queue.rs:485:33
      |
  485 |             let tail = unsafe { add_backlinks_and_find_tail(to_node(state)) };
      |                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  note: inside `sys::sync::rwlock::queue::RwLock::unlock_contended`
     --> library/std/src/sys/sync/rwlock/queue.rs:466:28
      |
  466 |                     return self.unlock_queue(next);
      |                            ^^^^^^^^^^^^^^^^^^^^^^^
  note: inside `sys::sync::rwlock::queue::RwLock::write_unlock`
     --> library/std/src/sys/sync/rwlock/queue.rs:450:22
      |
  450 |             unsafe { self.unlock_contended(state) }
      |                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  note: inside `<sync::rwlock::RwLockWriteGuard<'_, ()> as core::ops::Drop>::drop`
     --> library/std/src/sync/rwlock.rs:727:13
      |
  727 |             self.lock.inner.write_unlock();
      |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  note: inside `core::ptr::drop_in_place::<sync::rwlock::RwLockWriteGuard<'_, ()>> - shim(Some(sync::rwlock::RwLockWriteGuard<'_, ()>))`
     --> /checkout/library/core/src/ptr/mod.rs:542:1
      |
  542 | pub unsafe fn drop_in_place<T: ?Sized>(to_drop: *mut T) {
      | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  note: inside `core::mem::drop::<sync::rwlock::RwLockWriteGuard<'_, ()>>`
     --> /checkout/library/core/src/mem/mod.rs:938:24
      |
  938 | pub fn drop<T>(_x: T) {}
      |                        ^
  note: inside closure
     --> library/std/src/sync/rwlock/tests.rs:37:21
      |
  37  |                     drop(r.write().unwrap());
      |                     ^^^^^^^^^^^^^^^^^^^^^^^^
  
  note: some details are omitted, run with `MIRIFLAGS=-Zmiri-backtrace=full` for a verbose backtrace
  
  error: aborting due to 1 previous error
  
  error: test failed, to rerun pass `-p std --lib`
  
  Caused by:
    process didn't exit successfully: `/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/cargo-miri runner /checkout/obj/build/x86_64-unknown-linux-gnu/stage1-std/miri/aarch64-apple-darwin/debug/deps/std-7f3ec6b7438eabdc 'time::' 'sync::' 'thread::' 'env::' -Z unstable-options --format json` (exit status: 1)
  note: test exited abnormally; to see the full output pass --nocapture to the harness.
  Build completed unsuccessfully in 0:03:34
  make: *** [Makefile:61: check-aux] Error 1
    local time: Sun Jul 21 22:42:00 UTC 2024
    network time: Sun, 21 Jul 2024 22:42:00 GMT

It's not clear why this happened and we don't know what class of fluke this was. It can't be normal occurrences. It has to either be a miscompilation of some kind, spontaneous hardware memory corruption, or the worst case, and unfortunately one of the more likely cases, and the one that has given this issue its title: the stdlib has a genuine bug, but it can only be encountered once in a blue moon.

I am opening this issue because if this happens again, it needs to be reported somewhere. Hopefully any duplicate issues, if made, are eventually correlated.

[workingjubilee]

gdi it's #121950