[NTOSKRNL]
authorPierre Schweitzer <pierre@reactos.org>
Thu, 26 May 2016 12:09:05 +0000 (12:09 +0000)
committerPierre Schweitzer <pierre@reactos.org>
Thu, 26 May 2016 12:09:05 +0000 (12:09 +0000)
commit0b68260492f581723afa79044c31023c587898b3
tree1913c5a435a10e4faadaf4d10ad2216d273c6310
parentc43741c804243586aa2cf521de39d8359d60854e
[NTOSKRNL]
Rework a bit the way mapping and pinning is working in ReactOS Cc. This is still wrong regarding the way Windows does it, but at least, it offers us more features for a more compatible behavior exposed to FSDs.
First of all, reintroduce the mutex used to lock VACB. Moving there to a resource wasn't enough to work address the issue. This reverts r71387.
Introduce the resource in the BCB, as it should be. This resource will be unused until pinning occurs. In such case, the VACB mutex gets unused so that we can get the BCB released by another thread without deadlocking the associated VACB.
The VACB can be locked again after the last unpinning operation.
Basically, that fixes drivers than pin in a thread and unpin in another thread, after having changed BCB owner. Until now, it would just have deadlock or crashed ReactOS.
The implementation of this preserves hacks and stubplementations already in place in Cc (let's say it's another hack on top of hacks).
It was successfully tested with Ext2Fsd 0.66.

Short summary:
- Replace the VACB resource by a mutex
- Introduce a resource in the BCB
- Fixed CcPinRead() implementation so that it respects PIN_EXCLUSIVE flag
- Implement CcUnpinDataForThread() so that it can unpin data which ownership was changed
- Implement CcSetBcbOwnerPointer() so that it properly set BCB owner and allows unpinning with CcUnpinDataForThread()

CORE-11310 #resolve #comment Committed in r71406

svn path=/trunk/; revision=71406
reactos/ntoskrnl/cc/cacheman.c
reactos/ntoskrnl/cc/pin.c
reactos/ntoskrnl/cc/view.c
reactos/ntoskrnl/include/internal/cc.h
reactos/ntoskrnl/mm/section.c