In locore.S, the comments before [fs]uswintr claim that they are safe
to be called from an interrupt context. I think that they aren't, and I
was hoping someone could either confirm what I see, or give me the
missing clues.

	If they're called from an interrupt, then it is possible that another
of these user-data routines could have been running at the time that the
interrupt was received. When [fs]uswintr run, they set U_PCB_ONFAULT,
and then clear it when they're done. So when the interrupt returns, and
we resume running something like copyout (for example), it is running
with a 0 in U_PCB_ONFAULT. If you get a fault, the kernel panics.

	I know that this all sounds very theoretical, but it came up with some
improvements to user profiling that I've been looking into. The result
is that the profiling code can be called from interrupt (namely,
setrunnable()), and in particular can be called at splclock. So we're
processing a disk interrupt and doing a copyout() to the user, then a
clock interrupt happens and the profiling code calls [fs]uswintr.

	So, is this a bug? I eliminated the problem by changing [fs]uswintr to
be like kcopy, which saves the old value of U_PCB_ONFAULT.

	Thanks!
	-- Ethan