> Well does this raise a question over the use of kcopy() or uiomove()
> from
> interrupt contexts ?
> There are points where curproc and curpcb may be NULL and thus during
> these periods kcopy() cannot be used. If kcopy() is being indirectly
> called from an interrupt context this this would require that
> interrupts
> are always blocked if curproc/curpcb is zero.
> This means that perhaps there is a point where curpcb is zero but
> interrupts have not been disabled when they should have.
> 
I believe the m68k-based ports had a very similar problem when moving to
UVM. (I don't know if this also applies to arm32 though :)

For this, we had to modify kcopy so that it saved the previous value of
PCB_ONFAULT and restored it just before returning, instead of just
blindly clearing it on exit. You might need to do the same on the arm32
port.

Check out <m68k/m68k/copy.s> for details.

Cheers, Steve