fix: preserve parking_lot pointer provenance

[martintmk]

Summary

• pin parking_lot_core to upstream's provenance-safe AtomicPtr fix
• narrowly allow that upstream repository in cargo-deny while keeping unknown git sources denied
• keep the existing nightly strict-provenance Miri coverage unchanged

Root cause

Nightly run https://github.com/microsoft/oxidizer/actions/runs/31549925152 failed in miri-strict-provenance while running internity's freeze_races_writer_and_stays_prefix_consistent. Released parking_lot_core 0.9.12 stores a queue pointer in AtomicUsize and reconstructs it with an integer-to-pointer cast at word_lock.rs:320, which Miri rejects under -Zmiri-strict-provenance.

The pinned upstream commit fbfe854e, merged through Amanieu/parking_lot#499, changes WordLock to retain provenance with AtomicPtr. No patched crates.io release exists yet.

Bug: https://o365exchange.visualstudio.com/O365%20Core/_workitems/edit/7734570

Validation

• cargo +stable test -p internity --test basic freeze_races_writer_and_stays_prefix_consistent --all-features
• MIRIFLAGS=-Zmiri-strict-provenance cargo +nightly-2026-05-30 miri test -p internity --test basic --all-features -- freeze_preserves_handles_and_strings --exact
• cargo +stable check --workspace --all-features --locked
• cargo +stable sort --check --grouped --workspace
• cargo +stable deny check sources
• cargo +stable heather

The exact failing race test is Linux-only under Miri, so the unchanged GitHub nightly job provides the platform-exact validation.

[Copilot]

Pull request overview

Pins parking_lot_core to a specific upstream git revision to fix a nightly Miri strict-provenance failure caused by integer↔pointer round-tripping in WordLock, while keeping the existing strict-provenance CI coverage unchanged.

Changes:

• Add a [patch.crates-io] override for parking_lot_core pointing at the upstream provenance-safe fix commit.
• Update Cargo.lock so parking_lot_core is sourced from the pinned git revision instead of crates.io.

Reviewed changes

Copilot reviewed 1 out of 2 changed files in this pull request and generated 1 comment.

File	Description
Cargo.toml	Adds a crates.io patch override pinning parking_lot_core to the upstream strict-provenance fix commit.
Cargo.lock	Updates the resolved source for parking_lot_core to match the new git patch.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.0%. Comparing base (a650c15) to head (e5e8bde).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #664   +/-   ##
=======================================
  Coverage   100.0%   100.0%           
=======================================
  Files         503      503           
  Lines       57407    57407           
=======================================
  Hits        57407    57407           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Copilot]

Pull request overview

Copilot reviewed 22 out of 23 changed files in this pull request and generated no new comments.

[Copilot]

Pull request overview

Copilot reviewed 22 out of 23 changed files in this pull request and generated no new comments.

Suppressed comments (1)

.patches/parking_lot_core/Cargo.toml:11

• The vendored parking_lot_core now uses strict-provenance pointer APIs (e.g., ptr::without_provenance_mut, pointer .map_addr()/.with_addr()), which are not available on Rust 1.71. Keeping rust-version = "1.71.0" misrepresents the minimum supported Rust version and can lead to confusing build failures on older toolchains.

rust-version = "1.71.0"

[Copilot]

Pull request overview

Copilot reviewed 2 out of 3 changed files in this pull request and generated no new comments.

Suppressed comments (1)

deny.toml:67

• This comment says the allowlist is "commit-pinned", but allow-git only allows the repository URL (any commit). The commit pinning happens in Cargo.toml via rev, so the comment here is misleading.

# Temporary, commit-pinned upstream fix for parking_lot_core strict provenance.

[martintmk]

we don't want to use unknown repos, it exposes us to attacks

[martintmk]

investigate alternatives to this fix

[martin-kolinek]

🤖: Non-blocking — on "investigate alternatives to this fix" and the std suggestion, one data point so the follow-up isn't closed on a false premise: dropping parking_lot would not retire this patch unless internity moves too.

• cachet/src/refresh.rs:18 and cachet_tier/src/testing.rs:13 use only parking_lot::Mutex — a drop-in for std::sync::Mutex.
• internity/src/shard.rs:24,69,77 is built on RwLockUpgradableReadGuard, and std::sync::RwLock has no upgradable read at all. That fast path is a deliberate, documented concurrency tradeoff (shard.rs:13-22), so this is a redesign of the intern path, not a type swap.

And since anvil-miri-strict-provenance runs --all-features, internity's std feature keeps pulling parking_lot_core in — so a partial migration leaves the Miri failure exactly where it is.

[Sander Saares (sandersaares)]

Hmmm.

Do we even need parking_lot here? It can be a bit cargo-culted by AI sometimes. I suggest also trying with std synchronization primitives. They are better maintained and not necessarily slower.

[martin-kolinek]

🤖: The pinned revision is provenance-correct only under Miri, so the strict-provenance job and every ordinary build compile different code.

At this rev, core/src/word_lock.rs:17-32 selects atomic_ptr_fetch_byte_sub/atomic_ptr_fetch_and under #[cfg(not(miri))]; both cast &AtomicPtr<T> to *const AtomicUsize and perform an integer read-modify-write. Upstream's own comment on those lines says it: "we are loading the pointer stored in p at integer type, which discards provenance, and then storing that back, thus erasing the provenance in memory". The provenance-aware AtomicPtr::fetch_byte_sub/fetch_and versions (lines 34-42) are #[cfg(miri)] only.

Concretely: WordLock::unlock calls the non-Miri fetch_byte_sub, which erases the queue-head provenance that with_queue_head was careful to preserve via with_addr; unlock_slow then reloads that value and dereferences it. Contended parking_lot::Mutex/RwLock reach that bucket lock from entirely safe code in this workspace — e.g. concurrent internity::ThreadedLexicon::intern → crates/internity/src/shard.rs:68-78. And 0.9.12 at least got there through thread_data as *const _ as usize, an explicitly exposing pointer-to-integer cast that a later int-to-ptr cast can recover from; the polyfill drops that exposure.

The upstream FIXME above the #[cfg(miri)] versions reads "use this everywhere once we can depend on Rust 1.91" — this workspace already requires 1.93.1 (Cargo.toml:10), so the polyfill's reason to exist doesn't apply to us. Upstream keeps it because parking_lot_core declares rust-version = "1.71.0", and that MSRV won't move on our timeline.

There is no better revision to pin. fbfe854e is still HEAD for core/src/word_lock.rs on upstream master — the commits master is ahead by don't touch that file — and master's copy still has the polyfill cfg-gated exactly as above. crates.io's newest release, 0.9.12, predates this commit, so no published version contains even the polyfilled form. So the realistic options are:

1. Carry the one-line local patch — drop the cfg gate and call AtomicPtr::fetch_byte_sub/fetch_and unconditionally, which is sound at our 1.93.1 MSRV. That's the .patches/parking_lot_core/ shape an earlier revision of this PR had; re-adopting it means owning the CodeQL "Access of invalid pointer" alerts again (and it removes the need for the deny.toml allow-git carve-out entirely).
2. Accept Miri-only correctness and say so — the patch then buys a green scheduled job, not a provenance-correct shipped build. If that's the intent, it's worth stating in the [patch.crates-io] comment so the next reader doesn't over-read the PR title.

Upstreaming the ungating (an MSRV bump or a rustversion-style dispatch in parking_lot) is the durable fix, but it isn't available on this PR's timeline. Which of the two do you want here?

[martin-kolinek]

🤖: This is the first hole in the repo's unknown-git = "deny" posture, and as written it's wider than the change needs.

allow-git is URL-granular. This entry doesn't permit only the pinned commit; it permits any revision of Amanieu/parking_lot to enter the build from here on, including an unpinned branch dependency added later. The rev that makes today's build reproducible lives only in Cargo.toml/Cargo.lock — i.e. in exactly the thing the sources policy exists to constrain. Trusting a third-party repository at build time, rather than one immutable commit, is the substance of the concern, and it's closable with one more line in [sources] rather than by reversing the approach:

required-git-spec = "rev"

cargo-deny then rejects any allowed git source not pinned to a commit SHA, so the carve-out reads "this repo, at an immutable commit" instead of "this repo". (Worth noting the option in the blocking comment on Cargo.toml:351 — carrying the ungating as a local patch instead of a git [patch] — removes the need for this exemption altogether.)

Placement and cleanup trigger. This is the first adopter edit in the file to sit outside an anvil-managed block — [advisories].ignore (lines 10-29) and [licenses].allow (lines 34-49) both put adopter entries inside the block behind an Adopter-owned: comment, and those neighbours also carry an explicit removal trigger ("Tracked for removal once the upstream migration lands: "). As written the exemption is detached from the unknown-git = "deny" at line 65 it exists to relax, and "Temporary" has no link or exit criterion, so nothing here points at when it can go. Either the in-block pattern survives regeneration (and this should follow it) or it doesn't (and those two lists are already at risk) — worth settling one way.

(Cross-reference: this is the concrete narrowing for the concern raised on the Cargo.toml:351 thread — "we don't want to use unknown repos, it exposes us to attacks".)

[Sander Saares (sandersaares)]

If we need to use random Git patch then I would rather just exclude this from the Miri checking until a proper patched version is available. Plus file an upstream "hey release a fix please" issue.