Re: Kernel crash w/o reason

From: Robert Watson (rwatson_at_freebsd.org)
Date: 12/24/04

  • Next message: freebsd: "max data segment size problem (process can not allocate more then 1gb memory)" 
    Date: Fri, 24 Dec 2004 21:54:38 +0000 (GMT)
To: Jan Engelhardt <jengelh@linux01.gwdg.de>

    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@fledge.watson.org Principal Research Scientist, McAfee Research

    _______________________________________________
    freebsd-hackers@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
    To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"

  • Next message: freebsd: "max data segment size problem (process can not allocate more then 1gb memory)"

    Relevant Pages

    • [ANNOUNCE] Linux 2.6 Real Time Kernel - 2 (Mutex Patch)
      ... and the Linux system semaphore. ... +and task preemption latency in the current 2.6 kernel series. ... +- Priority Interiting Kernel Mutex substituting spinlocks in critical regions. ...
      (Linux-Kernel)
    • [PATCH 4/8] adaptive real-time lock support
      ... The Real Time patches to the Linux kernel converts the architecture ... compromising the integrity of critical sections protected by the lock. ... while retaining both the priority inheritance protocol as well as the ... the RT Mutex has been ...
      (Linux-Kernel)
    • Re: Priority Inheritance Test (Real-Time Preemption)
      ... That would indeed demand that the kernel would be Oin a lot of places ... subsystems can be used in real-time applications as well. ... resources with non-real-time applications. ... if the same mechanism is used for a userspace mutex there will be ...
      (Linux-Kernel)
    • [PATCH [RT] 00/14] RFC - adaptive real-time locks
      ... The Real Time patches to the Linux kernel converts the architecture ... inheritance protocol, and priority-ordered wait queues. ... contended lock to be preempted by higher priority tasks without ... the RT Mutex has been modified to busy-wait under ...
      (Linux-Kernel)
    • [patch 00/15] Generic Mutex Subsystem
      ... generic mutex subsystem that we have in the -rt kernel, ... 'simple mutex' code recently posted by David Howells.) ... 'struct mutex' is 16 bytes. ... than the semaphore based kernel, _and_ it also had 2.8 times less CPU ...
      (Linux-Kernel)