reactos-kernel

[ros-kernel] crash within MmOpenMemoryAreaByAddress

[Hartmut B. <har...@te...>]

Hi,

sometimes ros does crash with assertions from MmOpenMemoryAreaByAddress. 
Normaly this can not occur because the address space is locked at any 
operation that will manipulate it. This does not work for recursive calls 
from the same thread, because the lock is a MUTEX. For testing I've it 
changed to a FAST_MUTEX and do print out the calling functions and the 
stack trace (KeBugCheck does this) at a recursive call from the same 
thread. A simple test with 'gcc -o rdel.o rdel.c -c -pipe' crashs ros. The 
recursive functions are MmUnmapLockedPages and MmMapLockedPages. It seems, 
that a locked address space also must disable the task switching. For 
testing, I've added a KeRaiseIrql/KeLowerIrql at each lock/unlock for the 
kernel address space. This solve the problem. I think we must change the 
handling for address spaces and memory areas. At many points, where the 
address space is locked (access and paging faults), there must be locked 
the memory area from the address space and not the address space itself. 
All changes within the address space must occur without thread switching 
(irql raise to DISPATCH_LEVEL). Some functions must be split for a short 
lock time of address spaces (MmFreeMemoryArea).

Any ideas or comments?

- Hartmut

Re: [ros-kernel] crash within MmOpenMemoryAreaByAddress

[Casper H. <ch...@us...>]

s=F8n, 2002-05-12 kl. 13:50 skrev Hartmut Birr:
> Hi,
>=20
> sometimes ros does crash with assertions from MmOpenMemoryAreaByAddress.=20
> Normaly this can not occur because the address space is locked at any=20
> operation that will manipulate it. This does not work for recursive calls=
=20
> from the same thread, because the lock is a MUTEX. For testing I've it=20
> changed to a FAST_MUTEX and do print out the calling functions and the=20
> stack trace (KeBugCheck does this) at a recursive call from the same=20
> thread. A simple test with 'gcc -o rdel.o rdel.c -c -pipe' crashs ros. Th=
e=20
> recursive functions are MmUnmapLockedPages and MmMapLockedPages. It seems=
,=20
> that a locked address space also must disable the task switching. For=20
> testing, I've added a KeRaiseIrql/KeLowerIrql at each lock/unlock for the=
=20
> kernel address space. This solve the problem. I think we must change the=20
> handling for address spaces and memory areas. At many points, where the=20
> address space is locked (access and paging faults), there must be locked=20
> the memory area from the address space and not the address space itself.=20
> All changes within the address space must occur without thread switching=20
> (irql raise to DISPATCH_LEVEL). Some functions must be split for a short=20
> lock time of address spaces (MmFreeMemoryArea).
>=20
> Any ideas or comments?

This seem like a big change to the memory manager, so if nobody objects, th=
en
I would like to flush my changes to the memory manager to support a modifie=
d
page writer. Unfortunatly the system, in it's current state, deadlocks when=
 the
balance manager is run so it has to be disabled for now. This means that pa=
ging
to disk will not work until I or someone else get this fixed. With the bala=
ncer
disabled, it runs fine. Okay to commit?

Re: [ros-kernel] crash within MmOpenMemoryAreaByAddress

[<we...@cw...>]

Quoting Casper Hornstrup <ch...@us...>:
> 
> This seem like a big change to the memory manager, so if nobody objects,
> then I would like to flush my changes to the memory manager to support a
> modified page writer. Unfortunatly the system, in it's current state, 
> deadlocks when the balance manager is run so it has to be disabled for now. 
> This means that paging to disk will not work until I or someone else get this 
> fixed. With the balancer disabled, it runs fine. Okay to commit?
> 
I think it would be preferable to commit without known bugs. Why not post the
code to the list or commit to a seperate branch of the repository so more
people can help with debugging without having to break existing functionality.

Moreover I'm not sure that Harmutt Birr's suggestion is the best way to fix the
problem: I would prefer to special case the Mm{Unmap,Map}LockedPages function
rather than burden large parts of the memory manager with having to run at
DISPATCH_LEVEL. Firstly we could have a identity map of the first 256MB to
map one page, low memory reguests very fast (as NT does) and secondly a
dedicated region with the page tables already set up which can be 
guarded with a spinlock.

Re: [ros-kernel] crash within MmOpenMemoryAreaByAddress

[Casper H. <ch...@us...>]

man, 2002-05-13 kl. 15:43 skrev we...@cw...:
> Quoting Casper Hornstrup <ch...@us...>:
> > 
> > This seem like a big change to the memory manager, so if nobody objects,
> > then I would like to flush my changes to the memory manager to support a
> > modified page writer. Unfortunatly the system, in it's current state, 
> > deadlocks when the balance manager is run so it has to be disabled for now. 
> > This means that paging to disk will not work until I or someone else get this 
> > fixed. With the balancer disabled, it runs fine. Okay to commit?
> > 
> I think it would be preferable to commit without known bugs. Why not post the
> code to the list or commit to a seperate branch of the repository so more
> people can help with debugging without having to break existing functionality.

Yes, a seperate branch is better, I'll create one.

Re: [ros-kernel] crash within MmOpenMemoryAreaByAddress

[Casper H. <ch...@us...>]

man, 2002-05-13 kl. 20:33 skrev Casper Hornstrup:
> man, 2002-05-13 kl. 15:43 skrev we...@cw...:
> > Quoting Casper Hornstrup <ch...@us...>:
> > > 
> > > This seem like a big change to the memory manager, so if nobody objects,
> > > then I would like to flush my changes to the memory manager to support a
> > > modified page writer. Unfortunatly the system, in it's current state, 
> > > deadlocks when the balance manager is run so it has to be disabled for now. 
> > > This means that paging to disk will not work until I or someone else get this 
> > > fixed. With the balancer disabled, it runs fine. Okay to commit?
> > > 
> > I think it would be preferable to commit without known bugs. Why not post the
> > code to the list or commit to a seperate branch of the repository so more
> > people can help with debugging without having to break existing functionality.
> 
> Yes, a seperate branch is better, I'll create one.

I have created a branch named "mpw" for this change.