[ros-kernel] ExAllocatePool

Waldo Alvarez Cañizares wac at lab.matcom.uh.cu
Mon Feb 23 11:55:41 CET 2004


Hi Filip:
 
Great job!

 
________________________________

From: ros-kernel-bounces at reactos.com on behalf of Filip Navara
Sent: Sun 2/22/2004 7:32 AM
To: ros-kernel at reactos.com
Subject: [ros-kernel] ExAllocatePool



Hi all!

As Waldo Alvarez Cañizares pointed in one of his emails, the
ExAllocatePool function shouldn't zero out the memory returned. I tried
to fix it, but it's very hard to guess where it's really needed to zero
the memory or not. With the attached patch it's possible to boot and
work in the GUI, but obviously some places were ommited and it can cause
weird crashes (although I haven't seen any for a long time). I'm sending
it here for verification and asking the kernel developers to review it.

May I suggest you something?

You could create a new funtion for a while something like. ExAllocatePoolZero (or a Macro if you wish) and change the other calls to ExAllocatePool you are not sure, to call this new one. Then you could change one at a time and test it. If you are not sure you could leave it for a while until someone notices it (maybe the original developer). You could put a comment for a while like // We are not sure if zeroing memory is needed for this call change it if it doesn't.


We really need to fix this bug as soon as possible, otherwise it will be
even bigger pain to fix it then now.

True enought. With time it will grow more and more. There is another thing too, Windows DOES whole page allocations if size requested >= PAGE_SIZE. That could cause compatibility issues with drivers since some driver could ask some size and access the memory at the end of the block. I don't think it should be done that way for kernels not meant for production since that way it won't trash the kernel pool and will go unnoticed. Bot for a production system it should do it for compatibility.

Regards,
Filip

Best Regards
Waldo Alvarez



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 4600 bytes
Desc: not available
Url : http://reactos.com:8080/pipermail/ros-kernel/attachments/20040223/1f829d10/attachment-0001.bin


More information about the Ros-kernel mailing list