[NTOS:MM][NTOS:CC] Rewrite some cache memory management functions (#7510)

Use section object pointer with byte offset instead of using base address. This simplifies the Mm functions themselves and a

[NTOS:MM][NTOS:CC] Rewrite some cache memory management functions (#7510)

Use section object pointer with byte offset instead of using base address. This simplifies the Mm functions themselves and also the code in Cc that calls them.
Also add minor fixes for MmFlushSegment and MmPurgeSegment.

show more ...

[NTOS/CC] Fix broken usage of _SEH2_FINALLY

Finally handlers are - unlike except blocks - not part of the function they are in, but separate functions, which are called during unwind. PSEH implement

[NTOS/CC] Fix broken usage of _SEH2_FINALLY

Finally handlers are - unlike except blocks - not part of the function they are in, but separate functions, which are called during unwind. PSEH implements them on GCC using nested functions. While "return" from a finally handler is allowed with native SEH, it's handled by the compiler through an extra unwinding operation using _local_unwind, WHICH IS NOT SUPPORTED BY PSEH! With PSEH, returning from a finally handler does not return from the function, instead it will only return from the finally handler and the function will continue below the finally handler as if there was no return at all. To fix this, the return is removed and an additional success check is added.
Also use _SEH_VOLATILE to make sure the variable assignment is not optimized away by the compiler and add zero out the result parameters on error.

show more ...

[NTOS:CC] Raise status, when CcMapData fails (#3348)

Also add a check in fastfat, that asserts, when CcMapData returns FALSE.

[NTOS:MM][NTOS:CC] Performance improvement again

Read files by 64kb chunks instead of page-sized chunks.

[NTOS:CC] Fix a bug

[NTOS:CC][NTOS:MM] Try respecting ValidDataLength

[NTOS:CC] Get rid of ROS_VACB:Valid

[NTOS:CC] Properly return the public BCBs

[NTOS:CC] Perform sanity checks before doing anything else

[NTOS:CC] Always honor WriteThrough parameter in CcUnpinRepinnedBcb

[NTOS:CC] Fix some tests, complain where the current implementation won't let us do the right thing

[NTOS/CC] Be more precise when notifying Mm about dirty pages

[NTOSKRNL] Overhaul Cc and Mm relationship

Previously, when creating a file section, Mm requested Cc to cache the file, then Cc would request pages from Mm, then Mm would request them back to serve

[NTOSKRNL] Overhaul Cc and Mm relationship

Previously, when creating a file section, Mm requested Cc to cache the file, then Cc would request pages from Mm, then Mm would request them back to serve its file-mapping role
Now, Mm does it all by itself. If file cahcing is requested by the FS driver, then Cc creates a file mapping and uses that to serve its purpose.

This is a rewrite of Cc

show more ...

[NTOSKRNL] Drop the no longer needed Dirty field

CORE-15954

[NTOSKRNL] Don't mark VACB dirty on unpin

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

[NTOSKRNL] Don't mark VACB dirty on unpin

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

show more ...

[NTOSKRNL] Fix refcounting for BCBs

Now, we make sure that we update ref count and BCB list membership
with the BCB lock held, in a row.
This will avoid race conditions where the BCB was removed fro

[NTOSKRNL] Fix refcounting for BCBs

Now, we make sure that we update ref count and BCB list membership
with the BCB lock held, in a row.
This will avoid race conditions where the BCB was removed from the
list, then referenced again, leading to inconsistencies in memory
and crashes later on.
This could notably be triggered while building ReactOS on ReactOS
(one would call this a regression).

CORE-15235

show more ...

[NTOSKRNL] Call internal helper to get VACB on mapping
We already properly round our offset

[NTOSKRNL] Translate pinning flags to mapping flags when first mapping a file

[NTOSKRNL] Add the CcPinMappedDataCount counter

[NTOSKRNL] Rewrite the way we create BCB for pinning

We won't reuse a BCB created for mapping, we will now have
our own dedicated BCB.
This allows having a bit more cleaner implementation of CcPinMa

[NTOSKRNL] Rewrite the way we create BCB for pinning

We won't reuse a BCB created for mapping, we will now have
our own dedicated BCB.
This allows having a bit more cleaner implementation of CcPinMappedData()

show more ...

[NTOSKRNL] Don't keep the spin lock hold too long when we lost the BCB race

This will avoid a deadlock on unpin.

[NTOSKRNL] Rewrite BCB handling to be more robust

We now handle race conditions when creating BCB to avoid
having duplicated BCB per shared maps.
Also, we already specify whether the memory will be

[NTOSKRNL] Rewrite BCB handling to be more robust

We now handle race conditions when creating BCB to avoid
having duplicated BCB per shared maps.
Also, we already specify whether the memory will be pinned
when creating the BCB, to avoid potential duplications or
BCB misuse.

show more ...

[NTOSKRNL] Implement support for PIN_IF_BCB flag

[NTOSKRNL] When pinning data, try to find an already pinned BCB

If found, attempt to lock it and return it.

This fixes a lot of CcPinRead tests (and seems to speed up a bit ReactOS)

[NTOSKRNL] When mapping data, try to find if there's already a BCB

If so, return such BCB instead of creating a new one. This will
allow (at some point) to be more consistent in case of concurrent
m

[NTOSKRNL] When mapping data, try to find if there's already a BCB

If so, return such BCB instead of creating a new one. This will
allow (at some point) to be more consistent in case of concurrent
mapping.

This fixes a few CcMapData tests.

show more ...