cc: Fix dirty VACB list corruption causing FAST_FAIL_CORRUPT_LIST_ENTRY crashes

[Copilot]

Random BugCheck 0x139 (FAST_FAIL_CORRUPT_LIST_ENTRY) crashes during CcRosUnmarkDirtyVacb → RemoveEntryList caused by corrupted DirtyVacbListEntry Flink/Blink pointers. Three bugs in dirty VACB tracking:

Double-insert into dirty list (primary crash)

CcRosMarkDirtyVacb only had ASSERT(!Vacb->Dirty) — compiled out in release. Race:

1. CcRosFlushVacb calls CcRosUnmarkDirtyVacb → Dirty=FALSE, VACB removed from list
2. Concurrent writer calls CcRosMarkDirtyVacb → VACB inserted at tail, Dirty=TRUE
3. MmFlushSegment fails → CcRosMarkDirtyVacb called again → same node inserted twice

Second InsertTailList corrupts the previous tail's Flink without unlinking first. Next RemoveEntryList on a neighbor fails RtlpCheckListEntry → FAST_FAIL.

Fix: CcRosMarkDirtyVacb now checks Vacb->Dirty under the spinlock and returns early if already dirty.

Double-unmark (counter underflow / extra refcount drop)

CcRosUnmarkDirtyVacb only had ASSERT(Vacb->Dirty). CcFlushCache reads vacb->Dirty after CcRosLookupVacb releases its locks; lazy writer can flush the same VACB in the window, causing CcTotalDirtyPages/DirtyPages unsigned underflow and a spurious CcRosVacbDecRefCount.

Fix: CcRosUnmarkDirtyVacb now returns BOOLEAN and early-returns FALSE (under the lock) if Vacb->Dirty is already clear.

Unconditional re-mark on flush failure

CcRosFlushVacb always called CcRosMarkDirtyVacb on failure regardless of whether it had actually unmarked anything, compounding the double-insert risk.

Fix: CcRosFlushVacb captures the BOOLEAN from CcRosUnmarkDirtyVacb and only re-marks dirty on failure when WasMarked == TRUE.

Suspicious code annotated

Lockless vacb->Dirty reads in CcFlushCache and CcRosReleaseVacb are now commented explaining the races and why the new guards make them safe.

[tkreuzer]

@copilot Please explain better what "for correctness" means here. What could happen, if we bail out, when the VACB was not marked dirty at this point?

[Copilot]

Updated in the latest commit. The key point: if we bailed out early when WasMarked == FALSE, we'd return STATUS_SUCCESS to the caller without having verified that the section pages were actually written. The concurrent flush that beat us may have failed, meaning dirty data is still in the section. By always calling MmFlushSegment regardless of WasMarked, we get a reliable write status to return to the caller. We just must not re-mark dirty on failure in that case, since we were not the one who removed the VACB from the dirty list.

[tkreuzer]

@copilot What would happen here, if the VACB is unmarked dirty right after this check? Is that still a safe path? Add this to the comment.

[Copilot]

Updated in the latest commit. If Vacb->Dirty is TRUE at the check (so we skip CcRosMarkDirtyVacb) and a concurrent flush then immediately unmarks it, that flush's MmFlushSegment call covers all dirty section pages — including those written by the caller of this function before CcRosReleaseVacb was invoked. Should that flush fail, CcRosFlushVacb re-marks the VACB dirty via the WasMarked == TRUE path, ensuring a retry. No dirty data can be silently lost through this race.