Kernel crash w/o reason

[Robert Watson]

On Fri, 24 Dec 2004, Jan Engelhardt wrote:

> >> What should I use instead? A semaphore?
> 
> >You shouldn't have unrelated kernel threads waiting for a user
> >process at all, so this sounds like a design problem, regardless
> >of which mutual exclusion primitive you use.  (Bear in mind that I
> >haven't actually looked into what you're trying to do.)  In any
> >case, you can always use mutexes to implement whatever other
> >synchronization mechanism you need.
> 
> I wanted that the device can only be opened once, and holding a mutex
> while it is open seemed like a simple idea. (Since mtx_trylock() will
> then fail -- easy to implement.) 

Typically a mutex (mutex(9)) is used only for small periods of mutual
exclusion in accessing a data structure, and are not "sleepable locks" in
which unbounded waiting may occur by a user process in kernel.  For
sleepable locks, you might want to investigate an sx lock (sx(9)), or
possible construct a counted locking primitive using condition variables
and mutexes (condvar(9)).  I've not used our kernel counting semaphore
implementation (sema(9)) but would assume it falls nicely into the second
category and might be what you are looking for.  FreeBSD kernel locking
primitives are typically designed not to be held over potentially
unbounded periods, such as "return to userspace", and only some are
intended for use in semi-bounded periods (i.e., "wait on disk seek").
Most device drivers rely on a mutex and an internal access counter or
exclusive bit, FYI.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert at fledge.watson.org      Principal Research Scientist, McAfee Research