kernel locking - Minix

This is a discussion on kernel locking - Minix ; I was browsing through the source code and found kernel locks are implemented as intr_disable() and unlocking as intr_enable() -- not an entirely robust solution, surely? -- Philip Machanick...

+ Reply to Thread
Results 1 to 4 of 4

Thread: kernel locking

  1. kernel locking

    I was browsing through the source code and found kernel locks are
    implemented as intr_disable() and unlocking as intr_enable() -- not an
    entirely robust solution, surely?

    --
    Philip Machanick

  2. Re: kernel locking

    Philip Machanick wrote:
    > I was browsing through the source code and found kernel locks are
    > implemented as intr_disable() and unlocking as intr_enable() -- not an
    > entirely robust solution, surely?


    Why not?

    --
    Jens de Smit
    Student Computer Science | Vrije Universiteit Amsterdam
    jfdsmit@few.vu.nl | http://www.few.vu.nl/~jfdsmit
    "[In the end, people] get furious at IT that the goddamn magic isn't working"
    -- Stewart Dean

  3. Re: kernel locking

    In article ,
    "J.F. de Smit" wrote:

    > Philip Machanick wrote:
    > > I was browsing through the source code and found kernel locks are
    > > implemented as intr_disable() and unlocking as intr_enable() -- not an
    > > entirely robust solution, surely?

    >
    > Why not?


    Consider this scenario:

    lock (aka turn off interrupts)

    call a function which eventually leads to:
    lock /* bug if here when lock already held */

    do some stuff

    unlock (aka turn on interrupts)
    /* oops, 1st lock should still be held here */


    return

    do other stuff /* should be locked here not not */

    unlock

    Reaching the 2nd lock is a bug: with a proper lock, you would get stuck
    (since the kernel is not multithreaded). With the lock=turn off
    interrupts approach, you do not get stuck. Instead, between the inner
    "unlock" and the final one, you are running without mutual exclusion.

    Could lead to subtle, hard to track down bugs.

    I would rather the system would hang on an incorrect lock (or better
    still panic with a meaningful error message) than go on and maybe 1 time
    in 1000 give an incorrect result (in the presence of the nested lock
    bug).

    A safer implementation:

    /* initially */
    lock value = 0

    lock ()
    turn off interrupts
    if lock value == 1
    panic "nested kernel lock"
    else
    lock value = 1
    turn on interrupts

    unlock ()
    turn off interrupts
    lock value = 0
    turn on interrupts

    --
    Philip Machanick

  4. Re: kernel locking

    All,

    > Reaching the 2nd lock is a bug: with a proper lock, you would get stuck
    > (since the kernel is not multithreaded). With the lock=turn off
    > interrupts approach, you do not get stuck. Instead, between the inner
    > "unlock" and the final one, you are running without mutual exclusion.
    >
    > Could lead to subtle, hard to track down bugs.


    True. There are checks in the kernel (on k_reenter) that should not let
    this happen. There is also sanity check code to check if interrupts are
    already disabled when lock is called, if DEBUG_LOCK_CHECK is defined.

    =Ben



+ Reply to Thread