https://git.reactos.org/?p=reactos.git;a=commitdiff;h=bf164353035a2bc0f0d1d…
commit bf164353035a2bc0f0d1d679d09f2e4076498fa1
Author: Joachim Henze <Joachim.Henze(a)reactos.org>
AuthorDate: Sat Feb 5 01:06:15 2022 +0100
Commit: Joachim Henze <Joachim.Henze(a)reactos.org>
CommitDate: Sat Feb 5 01:06:15 2022 +0100
[WIN32SS] Remove an ambiguous assert entirely CORE-16738
It popped up very reliably when performing git-clone of the ros sources
while having the taskmgr open in the processes-tab.
Or when building 'ninja bootcd -j1' while having the taskmgr open in the processes-tab.
It is always possible to ignore it and then continue using ros for days without
noticing any side effects.
James Tabor judged the assert to have a "questionable logic".
Giannis who once added it, was also ok with commenting it.
His words:
This assertion isn't something fatal,
the worst thing that can happen from continuing on it would be
to make the thread get awake more times than it should.
It was commented out already on 2020-04-21 via
0.4.14-dev-1519-g 87f6c82d854583f71546841f4432f57e4a2d6c99
---
win32ss/user/ntuser/misc.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/win32ss/user/ntuser/misc.c b/win32ss/user/ntuser/misc.c
index 00393431603..8fa8b0edb4d 100644
--- a/win32ss/user/ntuser/misc.c
+++ b/win32ss/user/ntuser/misc.c
@@ -749,8 +749,6 @@ void UserDbgAssertThreadInfo(BOOL showCaller)
ASSERT(pci->ulClientDelta == DesktopHeapGetUserDelta());
if (pti->pcti && pci->pDeskInfo)
ASSERT(pci->pClientThreadInfo == (PVOID)((ULONG_PTR)pti->pcti - pci->ulClientDelta));
- //if (pti->pcti && IsListEmpty(&pti->SentMessagesListHead))
- // ASSERT((pti->pcti->fsChangeBits & QS_SENDMESSAGE) == 0);
if (pti->KeyboardLayout)
ASSERT(pci->hKL == pti->KeyboardLayout->hkl);
if(pti->rpdesk != NULL)
https://git.reactos.org/?p=reactos.git;a=commitdiff;h=8bd980e483a1a9154922b…
commit 8bd980e483a1a9154922bfa9bf96e1445575a894
Author: George Bișoc <george.bisoc(a)reactos.org>
AuthorDate: Sun Jan 30 11:12:31 2022 +0100
Commit: George Bișoc <george.bisoc(a)reactos.org>
CommitDate: Wed Feb 2 17:45:59 2022 +0100
[NTOS:CC] Unintialize private cache maps before purging the cache section
Before purging the data cache of a certain section of a file from system cache, we have to unintialize the private cache maps of that section if a filesystem or any other component prompts the kernel to do so.
---
ntoskrnl/cc/fs.c | 29 ++++++++++++++++++++++++-----
1 file changed, 24 insertions(+), 5 deletions(-)
diff --git a/ntoskrnl/cc/fs.c b/ntoskrnl/cc/fs.c
index bef6502f73f..14e3a4141a0 100644
--- a/ntoskrnl/cc/fs.c
+++ b/ntoskrnl/cc/fs.c
@@ -161,6 +161,7 @@ CcPurgeCacheSection (
IN BOOLEAN UninitializeCacheMaps)
{
PROS_SHARED_CACHE_MAP SharedCacheMap;
+ PPRIVATE_CACHE_MAP PrivateCacheMap;
LONGLONG StartOffset;
LONGLONG EndOffset;
LIST_ENTRY FreeList;
@@ -173,11 +174,7 @@ CcPurgeCacheSection (
CCTRACE(CC_API_DEBUG, "SectionObjectPointer=%p\n FileOffset=%p Length=%lu UninitializeCacheMaps=%d",
SectionObjectPointer, FileOffset, Length, UninitializeCacheMaps);
- if (UninitializeCacheMaps)
- {
- DPRINT1("FIXME: CcPurgeCacheSection not uninitializing private cache maps\n");
- }
-
+ /* Obtain the shared cache from the section */
SharedCacheMap = SectionObjectPointer->SharedCacheMap;
if (!SharedCacheMap)
{
@@ -185,6 +182,28 @@ CcPurgeCacheSection (
goto purgeMm;
}
+ if (UninitializeCacheMaps)
+ {
+ /*
+ * We have gotten the acknowledgement that
+ * the caller wants to unintialize the private
+ * cache maps so let's do this. Since we already
+ * have the shared cache map from above, iterate
+ * over that cache's private lists.
+ */
+ while (!IsListEmpty(&SharedCacheMap->PrivateList))
+ {
+ /*
+ * This list is not empty, grab the
+ * private cache map.
+ */
+ PrivateCacheMap = CONTAINING_RECORD(SharedCacheMap->PrivateList.Flink, PRIVATE_CACHE_MAP, PrivateLinks);
+
+ /* Unintialize the private cache now */
+ CcUninitializeCacheMap(PrivateCacheMap->FileObject, NULL, NULL);
+ }
+ }
+
StartOffset = FileOffset != NULL ? FileOffset->QuadPart : 0;
if (Length == 0 || FileOffset == NULL)
{