Lock ordering and ksched callbacks
authorBarret Rhoden <brho@cs.berkeley.edu>
Mon, 14 May 2012 20:43:24 +0000 (13:43 -0700)
committerBarret Rhoden <brho@cs.berkeley.edu>
Wed, 5 Sep 2012 21:43:58 +0000 (14:43 -0700)
commit58c5b087c6b29afc7e5f8172b79c4df4cf16331c
tree640859c871a3cd284606e8a965989cdc898b926c
parentfe0226d75bd969cc39acf846b2a7b96a1616d71e
Lock ordering and ksched callbacks

For now, there is no ordering between the proc lock and the ksched lock.
This commit revises a bunch of the scheduler callbacks (all clearly
prefixed with __sched).  These CBs can be triggered from lots of places,
specifically any proc code, any event code, and any code that kills a
process (like a PF handler!).

Since these grab locks, we needed to make the ksched let go of its lock
before calling into proc/event code (preempt_core() triggers events,
among other things).

This also moves the proc functions (like destroy) back into proc code,
since we no longer need to lock in the ksched before calling proc code.

We also can get rid of the 'ignore_next_idle'.  For now, we just wait
til the core has been given back in __core_req (no deadlock now, just a
race), instead of knowing it will be idle soon and circumventing the CB.
It's a toss-up between these two solutions.
kern/include/process.h
kern/include/schedule.h
kern/src/monitor.c
kern/src/process.c
kern/src/schedule.c