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?