cvs commit: src/sys/kern kern_event.c src/sys/sys eventvar.h

Doug Rabson dfr at
Wed Jul 14 15:23:26 PDT 2004

On Wednesday 14 July 2004 20:29, Robert Watson wrote:
> I like Doug's notion of using a task to handle some of the callbacks
> in a safe way.  We're already using this notion to simplify locking
> in the Jail code, so as to avoid vrele() requiring Giant in the
> process context, and I'm using it now in SLIP to perform the
> slstart() from a context that can safely acquire Giant so it can
> enter the tty subsystem.  Asynchrony, where sensible, can provide a
> clean solution to lock recursion/ordering issues. We use it for GEOM
> up/down threads, with ktrace, routing sockets, and so on.
> However, it has some limitations, in that it discards a lot of useful
> stack state for debugging, adds delays in notification (potentially
> somewhat unbounded) which can open up races itself, as well as other
> useful context.  It could well be simply inserting a task queue here
> solves the problem, but we'll want to be careful.  For example, in
> the SLIP code and Jail code, the 'struct task' used to perform the
> asynchronous notify is stored in the softc (or struct prison, which
> is basically a Jail softc).  In the Jail case, we know that the
> container prison can't be free()'d, because that's what the
> asynchronous notify does.  However, in the SLIP case I currently have
> no way to guarantee that the softc won't be free'd between the event
> being scheduled and running. Making sure this problem is cleanly
> addressed is going to be important in situations like pgsigio(),
> which involve pretty transient entities...

Given that the kernel eventually has good and predictable latencies for 
running swi threads, it seems to me that the main problem here is the 
race between posting a task on a queue and freeing that task. It ought 
to be possible to use the ta_pending count to detect the fact that a 
task is queued to help close up that class of race conditions 
(ta_pending is protected by the taskqueue mutex which implies that a 
given task must only ever be used with a single queue).

More information about the cvs-src mailing list