i386 lazy pmap switching in trap.c

[David Laight <david%l8s.co.uk@localhost>]

There seems to be copy in i386/i386/trap.c (and amd64) to do a deferred
pmap_load() in response to a T_PAGEFLT trap. (eg line 666)

Now I think that if the pmap hasn't been switched, then the active pmap
is going to to be that of a different process - so we will have just
copied to/from the wrong one (a trap from userspace will always have the
correct pmap loaded!).

At the same time as this code was added, code was added to (what is now)
copy.S to do the deferred pmap switch just before the copyin/out.
This would ensure that the pmap for the correct process was loaded, and
mean that curcpu()->ci_want_pmapload must always be false in the trap code.

Am I missing something?

        David

-- 
David Laight: david%l8s.co.uk@localhost