Intravision/reactos
1
0
Fork 0
mirror of https://github.com/reactos/reactos.git synced 2024-12-28 01:55:19 +00:00
Code Issues Projects Releases Packages Wiki Activity

[NTOSKRNL] Don't mark VACB dirty on unpin

Browse source 
This could happen if BCB was marked dirty previously.
Marking VACB dirty on unpin could lead to a double write of
the VACB, even if clean.
Indeed, now that setting BCB dirty leads to marking VACB
dirty, the VACB can be flushed in between by the lazy-writer.
The BCB state is not reset on VACB flush, contrary to the VACB state.
Thus, on unpin even if the VACB was already flushed, we were
setting back the dirty state, leading the VACB to be flushed again.

This could bring a small performance downgrade. Though it remains
limited since this is mostly used for FS metadata.
Possibly it could lead to metadata corruption, but this is likely
less possible.

CORE-15954
This commit is contained in:
Pierre Schweitzer 2019-04-17 22:23:57 +02:00
parent feb9c045cf
commit 8b6696fcdb
No known key found for this signature in database
GPG key ID: 7545556C3D585B0B
1 changed files with 12 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

14
ntoskrnl/cc/pin.c
View file

@ -169,10 +169,15 @@ CcpDereferenceBcb(
KeReleaseSpinLock(&SharedCacheMap->BcbSpinLock, OldIrql);
ASSERT(Bcb->PinCount == 0);
/*
* Don't mark dirty, if it was dirty,
* the VACB was already marked as such
* following the call to CcSetDirtyPinnedData
*/
CcRosReleaseVacb(SharedCacheMap,
Bcb->Vacb,
TRUE,
Bcb->Dirty,
FALSE,
FALSE);
ExDeleteResourceLite(&Bcb->Lock);
@ -682,10 +687,15 @@ CcUnpinRepinnedBcb (
ASSERT(iBcb->PinCount == 0);
}
/*
* Don't mark dirty, if it was dirty,
* the VACB was already marked as such
* following the call to CcSetDirtyPinnedData
*/
CcRosReleaseVacb(iBcb->Vacb->SharedCacheMap,
iBcb->Vacb,
TRUE,
iBcb->Dirty,
FALSE,
FALSE);
ExDeleteResourceLite(&iBcb->Lock);