hbirr@svn.reactos.com wrote:
Allocate the section object from non paged pool because the storage for a spin lock must be in non paged memory.
Hi,
Not that I disagree with your changes (it seems they are necessary) but don't they imply a bigger architectural problem? I've checked with WinOBJ and the Section Object is allocated in paged memory... just wanted to let you know this is why I made the change.
Best regards, Alex Ionescu
Alex Ionescu wrote:
Not that I disagree with your changes (it seems they are necessary) but don't they imply a bigger architectural problem? I've checked with WinOBJ and the Section Object is allocated in paged memory... just wanted to let you know this is why I made the change.
Well, then probably the spinlock in the section object was replaced with another synchronization object in newer releases of windows? The problem is you cannot have a spinlock structure in paged memory because as soon as you acquire it you assume it is paged in (which most probably will be the case), but you also assume it doesn't get paged out in the meanwhile (which is impossible on UP systems but could occur on SMP systems).
Best Regards, Thomas
Alex Ionescu wrote:
hbirr@svn.reactos.com wrote:
Allocate the section object from non paged pool because the storage for a spin lock must be in non paged memory.
Hi,
Not that I disagree with your changes (it seems they are necessary) but don't they imply a bigger architectural problem? I've checked with WinOBJ and the Section Object is allocated in paged memory... just wanted to let you know this is why I made the change.
Best regards, Alex Ionescu
I'm not sure what WinObj means with the paged and non paged memory. I see sections with both values set to zero and sections which using paged and non paged memory.
- Hartmut
Hartmut Birr wrote:
Alex Ionescu wrote:
hbirr@svn.reactos.com wrote:
Allocate the section object from non paged pool because the storage for a spin lock must be in non paged memory.
Hi,
Not that I disagree with your changes (it seems they are necessary) but don't they imply a bigger architectural problem? I've checked with WinOBJ and the Section Object is allocated in paged memory... just wanted to let you know this is why I made the change.
Best regards, Alex Ionescu
I'm not sure what WinObj means with the paged and non paged memory. I see sections with both values set to zero and sections which using paged and non paged memory.
- Hartmut
Here is the Object Type Initializer for Sections:
+0x060 TypeInfo : _OBJECT_TYPE_INITIALIZER +0x000 Length : 0x4c +0x002 UseDefaultObject : 0x1 '' +0x003 CaseInsensitive : 0 '' +0x004 InvalidAttributes : 0x100 +0x008 GenericMapping : _GENERIC_MAPPING +0x000 GenericRead : 0x20005 +0x004 GenericWrite : 0x20002 +0x008 GenericExecute : 0x20008 +0x00c GenericAll : 0xf001f +0x018 ValidAccessMask : 0x1f001f +0x01c SecurityRequired : 0 '' +0x01d MaintainHandleCount : 0 '' +0x01e MaintainTypeList : 0 '' +0x020 PoolType : 1 ( PagedPool ) <========= +0x024 DefaultPagedPoolCharge : 0x58 <=========
So the objects are in the Paged Pool.
Best regards, Alex Ionescu
Alex Ionescu wrote:
Here is the Object Type Initializer for Sections:
+0x060 TypeInfo : _OBJECT_TYPE_INITIALIZER +0x000 Length : 0x4c +0x002 UseDefaultObject : 0x1 '' +0x003 CaseInsensitive : 0 '' +0x004 InvalidAttributes : 0x100 +0x008 GenericMapping : _GENERIC_MAPPING +0x000 GenericRead : 0x20005 +0x004 GenericWrite : 0x20002 +0x008 GenericExecute : 0x20008 +0x00c GenericAll : 0xf001f +0x018 ValidAccessMask : 0x1f001f +0x01c SecurityRequired : 0 '' +0x01d MaintainHandleCount : 0 '' +0x01e MaintainTypeList : 0 '' +0x020 PoolType : 1 ( PagedPool ) <========= +0x024 DefaultPagedPoolCharge : 0x58 <=========
So the objects are in the Paged Pool.
I'm removing the ViewListHead and ViewListLock from section object. This members are only used for finding the start address of an image. The start address can be calculated from each segment of a section object.
- Hartmut