Windows: Race between NonCached and Cached Writes

The following race was identified by Rod Widdowson.

 A. File is complete up to 1000 Eof=1000, VDL=1000
 B. File Eof is set to 2000.  Eof=2000, VDL=1000 (SetInfo doesn't move VDL)
 C. Locks dropped.

Thread1) Write comes in for 1000 for 500.  This is not extending.
         Locks taken shared.
Thread1) Data Written to Server.  Thread stalls.
Thread2) Read comes in for 1000 for 1000.  Locks taken shared
         so it proceeds.
Thread2) CcRead calls CcZero and so the cache get zeros from 1000 to 2000
Thread1) VDL moves forward.

The windows cache is now poisoned between 1000 and 1500 and protected by
the VDL.  Any future reads gets the wrong data and any write to that part
will cause an overwrite of zeros.

Instead of holding the Fcb->NPFcb->Resource and
Fcb->NPFcb->SectionObjectResource shared during a NonCached write, hold it
exclusive because the write is occurring behind the back of the windows
cache.

Change-Id: I2244e1247dcee2c3ca0d95e6ee11de3187d491c5
Reviewed-on: http://gerrit.openafs.org/9754
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Rod Widdowson <rdw@steadingsoftware.com>
Reviewed-by: Peter Scott <pscott@kerneldrivers.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
This commit is contained in:
Jeffrey Altman 2013-04-09 08:12:29 -04:00
parent 4a40c1f663
commit 7bb300ad2c

View File

@ -516,7 +516,7 @@ AFSCommonWrite( IN PDEVICE_OBJECT DeviceObject,
(liStartingByte.LowPart == FILE_WRITE_TO_END_OF_FILE && (liStartingByte.LowPart == FILE_WRITE_TO_END_OF_FILE &&
liStartingByte.HighPart == -1)) ; liStartingByte.HighPart == -1)) ;
if( bExtendingWrite) if( bExtendingWrite || bNonCachedIo)
{ {
// //
// Check for lock inversion // Check for lock inversion