ASSERT_IRQL and unrelated mm/mdl.c

[art yerkes]

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.
-- 
Hey, Adam Smith, keep your invisible hands to yourself!

[art yerkes]

>   Unrelated, please take a look at the following patch,
> anyone who's cozy
>  with the mm.  
Sorry forgot the attachment.
-- 
Hey, Adam Smith, keep your invisible hands to yourself!

[David Welch]

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?

[art yerkes]

On Wed, 29 Sep 2004 09:01:55 +0100
David Welch <welch(a)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!

[Hartmut Birr]

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(a)reactos.com 
>  [mailto:[e-mail]] On Behalf Of art yerkes
>  Sent: Wednesday, September 29, 2004 3:16 PM
>  To: ReactOS Development List
>  Cc: welch(a)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(a)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(a)reactos.com
>  http://reactos.com:8080/mailman/listinfo/ros-dev
>