[lkml]   [2006]   [Nov]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 2.6.19 5/5] fs: freeze_bdev with semaphore not mutex

    > You're asking me? ;)
    > Guys, I'm going to park this patch pending a full description of what it
    > does, a description of what the above hunk is doing and pending an
    > examination of whether we'd be better off changing the mutex-debugging code
    > rather than switching to semaphores.

    It's not used as a mutex. Sad but true. It's not so easy to say "just
    shut up the debug code", because it's just not that easy: The interface
    allows double "unlock", which is fine for semaphores for example. There
    fundamentally is no "owner" for this case, and all the mutex concepts
    assume that there is an owner. If the owner goes away, pointers to their
    task struct for example are no longer valid (used by lockdep and the
    other debugging parts). It's what makes the difference between a mutex
    and a semaphore: a mutex has an owner and several semantics follow from
    that. These semantics allow a more efficient implementation (no multiple
    "owners" possible) but once you go away from that fundamental property,
    soon we'll see "oh and it needs <this extra code> to cover the wider
    semantics correctly.. and soon you have a semaphore again.

    Let true semaphores be semaphores, and make all real mutexes mutexes.
    But lets not make actual semaphores use mutex code...

    if you want to mail me at work (you don't), use arjan (at)
    Test the interaction between Linux and your BIOS via

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-11-08 10:59    [W:0.020 / U:5.016 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site