I started putting in ASSERT_IRQL in ntoskrnl, hoping that only my own code would break from it. The results are ... interesting.
I've put a metabug (426) on bugzilla which is about reactos not honoring documented irql requirements. I fixed a place in win32k.sys, but there are probably more. I think we should clean these up and get the assert_irqls into HEAD, so that people like me won't get bitten over and over by assuming we're in one irql when we're in another.
Unrelated, please take a look at the following patch, anyone who's cozy with the mm. The reason why this code is needed is that MmNotPresentFault and MmAccessFault will try to lock the address space as well as MmProbeAndLockPages. Since this is a spin lock, reactos will always bugcheck when MmProbeAndLockPages faults in a page, even if that would be legal otherwise. I'm not sure if this patch fixes it right but it does seem to work this way. If i don't hear too many complaints i'll think about committing something similar.
There are a couple of other places where MmNotPresentFault is called (section.c) within a MmLockAddressSpace. Another idea would be to give MmNotPresentFault and MmAccessFault an extra argument so they can ignore locking if the address space is already locked.
On Tue, Sep 28, 2004 at 11:16:35PM -0500, art yerkes wrote:
There are a couple of other places where MmNotPresentFault is called (section.c) within a MmLockAddressSpace. Another idea would be to give MmNotPresentFault and MmAccessFault an extra argument so they can ignore locking if the address space is already locked.
Isn't that what already happens? The FromMdl argument. And isn't the address space lock a fast mutex not a spinlock?
On Wed, 29 Sep 2004 09:01:55 +0100 David Welch welch@cwcom.net wrote:
On Tue, Sep 28, 2004 at 11:16:35PM -0500, art yerkes wrote:
There are a couple of other places where MmNotPresentFault is called (section.c) within a MmLockAddressSpace. Another idea would be to give MmNotPresentFault and MmAccessFault an extra argument so they can ignore locking if the address space is already locked.
Isn't that what already happens? The FromMdl argument. And isn't the address space lock a fast mutex not a spinlock?
It wasn't always honored but Hartmut fixed it in mm/mm.c without my noticing (1.76). Sorry I fell behind.
Hi,
there is still another bug in MmProbeAndLockPages. It is always locked the address space of the current process, even if the address is located within the kernel address space. In this case it must lock the kernel address space.
- Hartmut
-----Original Message----- From: ros-dev-bounces@reactos.com [mailto:ros-dev-bounces@reactos.com] On Behalf Of art yerkes Sent: Wednesday, September 29, 2004 3:16 PM To: ReactOS Development List Cc: welch@cwcom.net Subject: Re: [ros-dev] ASSERT_IRQL and unrelated mm/mdl.c
On Wed, 29 Sep 2004 09:01:55 +0100 David Welch welch@cwcom.net wrote:
On Tue, Sep 28, 2004 at 11:16:35PM -0500, art yerkes wrote:
There are a couple of other places where
MmNotPresentFault is called
(section.c) within a MmLockAddressSpace. Another idea
would be to give
MmNotPresentFault and MmAccessFault an extra argument so
they can ignore
locking if the address space is already locked.
Isn't that what already happens? The FromMdl argument. And
isn't the address
space lock a fast mutex not a spinlock?
It wasn't always honored but Hartmut fixed it in mm/mm.c without my noticing (1.76). Sorry I fell behind. -- Hey, Adam Smith, keep your invisible hands to yourself! _______________________________________________ Ros-dev mailing list Ros-dev@reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev
-
art yerkes -
David Welch -
Hartmut Birr