Ensures IRQs are enabled when proc_destroy()ing
authorBarret Rhoden <brho@cs.berkeley.edu>
Mon, 14 May 2012 22:00:49 +0000 (15:00 -0700)
committerBarret Rhoden <brho@cs.berkeley.edu>
Wed, 5 Sep 2012 21:43:58 +0000 (14:43 -0700)
commit850e1a46dbe89e3657ea858e93bc417ce597dc77
treec1a63302a2a4489c29cde599f756a864952653b7
parentc3654267a3057044adb7ff3f3b85142a299bbdad
Ensures IRQs are enabled when proc_destroy()ing

The main reason is that irqs need to be on when grabbing the proclock.
There are some deadlock scenarios where a __preempt (or even __death)
kmsg is sent with the lock held to a core, but if that core has irqs
disabled, it won't process the message (circular waiting, etc).

While I could make proc_destroy() enable irqs, its really up to the
calling code to do that.  I put in asserts where they shouldn't be
disabled, and otherwise turned them on manually.  This mostly applies to
trap handling code.  Note we can't just turn on IRQs immediately - each
case needs to do it where it is possible (preferably sooner than later),
such as after reading cr2() in x86's PF handler.
kern/arch/i686/trap.c
kern/arch/riscv/trap.c
kern/arch/sparc/trap.c
kern/src/manager.c
kern/src/monitor.c
kern/src/process.c
kern/src/syscall.c