Re: [ros-dev] [ros-diffs] [jgardou] 55770: [NTOSKRNL/MM] - finally, release user shared data at process address space cleanup. - release PDE pages that might not be freed at process end. - Let the caller handle PDE release ...

[Jérôme Gardou]

Le 21/02/2012 01:32, jgardou(a)svn.reactos.org a écrit :
>   Author: jgardou
>  Date: Tue Feb 21 00:32:24 2012
>  New Revision: 55770
>
>  URL: http://svn.reactos.org/svn/reactos?rev=55770&view=rev
>  Log:
>  [NTOSKRNL/MM]
>    - finally, release user shared data at process address space cleanup.
>    - release PDE pages that might not be freed at process end.
>    - Let the caller handle PDE release when deleting a PTE
>    - restore Richard's ASSERT : All user PDE pages are now freed! 
Addendum to
log :
     When a page maps a Prototype PTE, we can't know if it must be 
deleted before dropping shared reference. Modify ASSERT accordingly.
     Restore the ASSERTion that only page fault should provocate the 
creation of the PDE and modify PDE refcounting in pageout code accordingly.

[Thomas Faber]

Hey Jérôme,

On 2012-02-21 01:40, Jérôme Gardou wrote:

>   Le 21/02/2012 01:32, jgardou(a)svn.reactos.org a écrit
> :
> >   Author: jgardou
> >  Date: Tue Feb 21 00:32:24 2012
> >  New Revision: 55770
> >
> >  URL: http://svn.reactos.org/svn/reactos?rev=55770&view=rev
> >  Log:
> >  [NTOSKRNL/MM]
> >    - finally, release user shared data at process address space cleanup.
> >    - release PDE pages that might not be freed at process end.
> >    - Let the caller handle PDE release when deleting a PTE
> >    - restore Richard's ASSERT : All user PDE pages are now freed! 
>  Addendum to
> log :
>      When a page maps a Prototype PTE, we can't know if it must be deleted before
> dropping shared reference. Modify ASSERT accordingly.
>      Restore the ASSERTion that only page fault should provocate the creation of the PDE
> and modify PDE refcounting in pageout code accordingly. 

there's a kernel assertion failure after (!) the kernel32:virtual
test starting with this revision (that of course doesn't show up
in Testman results. Evil).
It's a different failure in VirtualBox vs. KVM apparently.

Perhaps you have an idea where this comes from?

r55770 VBox
http://reactos.org/testman/detail.php?id=4209391&prev=0
r55770 KVM
http://reactos.org/testman/detail.php?id=4206792&prev=0

r55769 VBox
http://reactos.org/testman/detail.php?id=4211387&prev=0
r55769 KVM
http://reactos.org/testman/detail.php?id=4208788&prev=0

Regards,
Tom