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. ---