Bug 71109

pmap_allocpte() and pmap_enter_quick() in 'src/sys/i386/i386/pmap.c'
both call pmap_page_lookup() and _pmap_allocpte().  The latter two
functions may return NULL, which can be an indicator that the
respective function has been blocking.  The caller is then supposed
to start over again since the current operation at this level can
no longer be considered atomic.

Now, in pmap_allocpte() the return value of pmap_page_lookup()
isn't checked for NULL, and in pmap_enter_quick() the same is
true for _pmap_allocpte().  These flaws cause race conditions
that can result in a kernel panic.

Fix: Please consider adopting the patch below.  It applies cleanly to
RELENG_4 as of today, and, as far as I can tell, also applies to
the Alpha architecture (possibly with minor tweaks).

Apart from adding the missing NULL checking we also optimize the
other, already existing NULL check in pmap_enter_quick() in that
we do it only after pmap_page_lookup() has been called, because
'mpte' cannot be NULL in case the first part of the if-else clause
gets executed.

This patch also removes a superfluous call of VM_WAIT in
_pmap_allocpte().  The preceding function vm_page_grab() already
does the appropriate sleeping before returning NULL, even if called
without the VM_ALLOC_RETRY flag.  So we can return from
_pmap_allocpte() right away.

How-To-Repeat: The problem becomes apparent when looking at the relevant source
code.