Expanding the scanner surface per user directive "all should be
addressed". Four distinct root causes for CPU-side violations around
GPU-owned data — each with its own scan command, fix hierarchy, and
learned-patterns entry.
- CPURO: CPU reads of GPU-resident data (sizes, reductions) that
force implicit sync. Cache at construction, keep stats on device.
- ROMEM: `*(ptr as *mut T)` writes where ptr came from a const /
read-only source. CUDA mapped-memory flags matter; cuBLAS/cuDNN
workspace casts are benign FFI.
- LOCKHOT: Mutex/RwLock on per-step path. High-value hits already
visible: Mutex<GpuDropout>, Mutex<Option<DropoutScheduler>> in
network.rs (every forward pass), Arc<Mutex<NStepBuffer>> in dqn.rs.
Never hold tokio::sync::RwLock across .await.
- BORROW: shared-&T promoted to &mut T via unsafe ptr casts or
UnsafeCell/RefCell. Real example shipped: gpu_replay_buffer.rs:690
changes CudaSlice<i32> → CudaSlice<u32> through raw-ptr cast.
Scoreboard seeded with 10 findings. Top scores:
- ROMEM-001 (25.0) - size_pinned mapped write, verify allocation flag
- ROMEM-004 (25.0) - cuBLAS workspace casts, likely false-positive bulk
- ROMEM-002 (15.0) - init-time pinned mapped writes
- LOCKHOT-001/002/003 (8.3) - dropout + nstep_buffer locks on hot path
- BORROW-001 (8.3) - CudaSlice element-type aliasing
CPURO is seeded with a scan-task (CPURO-000) to populate per-site
findings in iter 9 — too many Vec::len() false positives to list upfront.
aa0996f3c6