Kthreads launched from KMSGs are tracked as ktasks
authorBarret Rhoden <brho@cs.berkeley.edu>
Thu, 3 Oct 2013 23:44:57 +0000 (16:44 -0700)
committerBarret Rhoden <brho@cs.berkeley.edu>
Thu, 16 Jan 2014 02:18:05 +0000 (18:18 -0800)
commit4812f9842e889d75ea67650af04bb69f7887d03d
treedbb600a0837e99c142a53fcf943d7d92dd851af7
parent3c080994f0d29fe8c08e3a08ef37956c42440dce
Kthreads launched from KMSGs are tracked as ktasks

The kernel tasks don't have a particular address space, and won't store a
reference to whatever process happens to be running.  Previously, things like
loopbackread() would save a reference to whatever process happened to be
running there, which would keep that process from fully DYING.

Any routine kernel message will have is_ktask set.  If they block, the kthread
code will know to handle these differently.  This means that syscall context
shouldn't somehow try to execute as an RKM.  As a reminder, when you first
launch an RKM, it is in early_rkm_ctx.  So put another way, no syscall work or
other work on behalf of a process that can block should execute in
early_rkm_ctx().  Anyway, this all is subject to change, if I need to.
Comments inline will track the latest.
kern/include/kthread.h
kern/src/kthread.c
kern/src/process.c
kern/src/smp.c
kern/src/trap.c