Fix lock debugging issue with page faults and IRQs
authorBarret Rhoden <brho@cs.berkeley.edu>
Fri, 4 Dec 2015 20:48:02 +0000 (15:48 -0500)
committerBarret Rhoden <brho@cs.berkeley.edu>
Thu, 10 Dec 2015 15:40:20 +0000 (10:40 -0500)
commit48d3aea190cd33b6a3fe725c5e2cf860cf14b0de
tree117f0f48fd88c7d8642560356ffb3ba21d368aaf
parent3f805ed22943bb2f09db8611b5d896a31467acf5
Fix lock debugging issue with page faults and IRQs

There was a brief window between enabling IRQs and disabling lock checking.
If you receive an IRQ in here and that IRQ grabs a lock (e.g. timer IRQ),
you'll panic.

If you build with spinlock debugging and execute something like:

/ $ ash looper.sh prov -p1 -tc -m > /dev/null

and wait a minute or two, you'll catch a bug.  What's going on is that
looper and prov eventually get the kernel to trigger a soft page fault.
Then we get an IRQ during the window after enable_irq.  The lock debugger
flips out since we grab a lock with a kernel trap depth, which is
dangerous.  The old code was trying to work around this by disabling the
debugger, but it should have done so before enabling interrupts.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
kern/arch/x86/trap.c