Fix: close profiler drain and mapping races - #2145
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Team Run ID: 📒 Files selected for processing (4)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthroughThe changes add reader-writer locking to host pointer mappings and align profiler quiescence acknowledgements with queue sweeps. Unit tests cover concurrent mapping resolution and explicit buffer publication ordering. ChangesHost mapping synchronization
Profiler drain epoch ordering
Estimated code review effort: 3 (Moderate) | ~20 minutes Merge Risk: ⚪ Minimal · up to This change synchronizes concurrent host-mapping access and makes profiler drain acknowledgements correspond to post-epoch sweeps, with updated coverage for concurrent resolution and publication ordering. No concrete current-head merge-blocking risk remains. Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Synchronize dynamic mapping updates with drain-time pointer resolution using shared reader and exclusive writer locking. Cover exact and range lookups under concurrent block registration. Observe each quiesce epoch before its drain sweep so an acknowledgement cannot use stale work. Add a gated regression test that reproduces the stale-sweep acknowledgement ordering. Keep the profiling concurrency contract aligned with the implementation and use the repository's pragma-once convention in touched headers.
843af9e to
b73cd64
Compare
Problem
Runtime replenishment can append to
dev_to_host_andblock_ranges_while drain shards call
resolve_host_ptr(). The writer heldmapping_mutex_, but the reader relied on an invalid immutability assumption,so container rehash or reallocation could race with lookup.
The drain loop also loaded the requested quiesce epoch after scanning its
queues. A sweep that began before the request could therefore acknowledge the
new epoch and let export begin before records published during that sweep were
drained.
Follow-up to #2127.
Changes
keeping runtime mutation under the exclusive lock.
acknowledge that epoch after the sweep reports no work.
the stale-sweep acknowledgement ordering.
the mapping ownership contract, and apply the repository's
#pragma onceconvention to the touched headers.
Reviewer guide
The main correctness boundaries are the lifetime of the shared mapping lock in
resolve_host_ptr()and the placement of the acquire-load before the completequeue sweep in
mgmt_drain_loop().Testing
test_profiler_base: 10/10 passedpassed 20 consecutive runs