Subject: Re: UVM/PMAP_NEW on i386 panics ... not anymore
To: Matthias Drochner <drochner@zelux6.zel.kfa-juelich.de>
From: Stefan Grefen <grefen@hprc.tandem.com>
List: port-i386
Date: 05/22/1998 17:28:57
In message <MpNKlk66LiYE4I1Zx=@zelux6>  Matthias Drochner wrote:
> Excerpts from netbsd: 20-May-98 Re: UVM/PMAP_NEW on i386 pa.. Stefan
> Grefen@hprc.tande (2312)
> 
> > The problem is that if the pte page for an virtual address is not there, 
> > the I386 copyout code traps trying to testb the pte for this va. 
> > uvm can't page the pte page in and but because copyfault is set 
> > copyout just returns EFAULT via copyfault instead of panicing on the kernel
> > page-fault.
> 
> I've understood this too in the meantime. The patch I checked
> in on Wednesday (locore 1.192, trap 1.113) addresses the same.

I guess it was THE time to solve this problem :-))

> Perhaps in a more expensive way, but cleaner. (Your |=PSL_Z
> depends a lot on a "testb" done in all copyout-like functions, so
> it is really dangerous.)

Not more than relying on the call to a function. If we would wrap the
testb ; jz in a macro, than we would be as save as calling the 
function I think.
The realy nasty thing is, that it doesn't panic when it happens, 
the panics are only symptoms. Something like fubyte could go unoticed
for a long time. 
I would even add a check (at least with DIAGNOSTIC) to the trap code
to panic if this happens on a pc outside of locore.s or so.

Something like:
#define TEST_PAGE_WRITABLE(_page,_fault) testb   $PG_RW,_PTmap(,_page,4);\  
					 jz   _fault

> Do you see performance differences?

I'll test it, I will have results after the weekend.
I expect to see a difference in syscall performance.

Stefan

> 
> best regards
> Matthias

--
Stefan Grefen                                Tandem Computers Europe Inc.
grefen@hprc.tandem.com                       High Performance Research Center
 --- Hacking's just another word for nothing left to kludge. ---