[ros-kernel] Bug in NtAllocateVirtualMemory

Hartmut Birr hartmut.birr at gmx.de
Sun Feb 1 18:29:17 CET 2004


Hi,

it seems there exist some more problems in the handling of section and
virtual memory. If a page is accessed directly (page in, page out or
flush to disk) there is allocated a pageop and nobody will do anything
with such a page. The problems are function like NtAllocateVirtualMemory
or NtProtectVirtualMemory. They don't check for an pageop but they does
change the page protection. Functions which use a pageop don't check for
such changes. I think a pageop should be for a range of pages and all
functions must allocate a pageop. If a pageop is for more as one page,
it is easier to implement page clustering on page faults or while
writing back pages. Any ideas?

- Hartmut     

> -----Original Message-----
> From: ros-kernel-bounces at reactos.com 
> [mailto:ros-kernel-bounces at reactos.com] On Behalf Of Filip Navara
> Sent: Sunday, February 01, 2004 12:04 AM
> To: ReactOS Kernel List
> Subject: [ros-kernel] Bug in NtAllocateVirtualMemory
> 
> 
> Hi,
> 
> I need help some help from educated kernel person again. I found that 
> the attached code from ATL doesn't work under ReactOS. The 
> cause is that 
> in ReactOS it's not possible to call NtAllocateVirtualMemory on 
> MEMORY_AREA_SECTION_VIEW memory area with specified prefered base 
> address and MEM_COMMIT flag. I have no idea how this 
> situation should be 
> handled correctly, so I'm using this hack right now:
> 
>     MemoryArea = MmOpenMemoryAreaByAddress(AddressSpace,
>                            BaseAddress);
>    
> +    if (MemoryArea != NULL &&
> +        MemoryArea->Type == MEMORY_AREA_SECTION_VIEW &&
> +        MemoryArea->Length >= RegionSize)
> +      {
> +        MmUnlockAddressSpace(AddressSpace);
> +        ObDereferenceObject(Process);
> +        return STATUS_SUCCESS;
> +      }
>     else if (MemoryArea != NULL &&
>          MemoryArea->Type == MEMORY_AREA_VIRTUAL_MEMORY &&
>          MemoryArea->Length >= RegionSize)
> 
> Regards,
> Filip
> 
> 



More information about the Ros-kernel mailing list