12 Jul, 2013

1 commit

  • Oleg Nesterov recently noticed that the lockdep annotations in lglock.c
    are not sufficient to detect some obvious deadlocks, such as
    lg_local_lock(LOCK) + lg_local_lock(LOCK) or spin_lock(X) +
    lg_local_lock(Y) vs lg_local_lock(Y) + spin_lock(X).

    Both issues are easily fixed by indicating to lockdep that lglock's local
    locks are not recursive. We shouldn't use the rwlock acquire/release
    functions here, as lglock doesn't share the same semantics. Instead we
    can base our lockdep annotations on the lock_acquire_shared (for local
    lglock) and lock_acquire_exclusive (for global lglock) helpers.

    I am not proposing new lglock specific helpers as I don't see the point of
    the existing second level of helpers :)

    Noticed-by: Oleg Nesterov
    Signed-off-by: Michel Lespinasse
    Cc: Lai Jiangshan
    Cc: "Srivatsa S. Bhat"
    Cc: Rusty Russell
    Cc: Andi Kleen
    Cc: "Paul E. McKenney"
    Cc: Steven Rostedt
    Signed-off-by: Andrew Morton
    Signed-off-by: Peter Zijlstra
    Link: http://lkml.kernel.org/r/20130708212352.1769031C15E@corp2gmr1-1.hot.corp.google.com
    Signed-off-by: Ingo Molnar

    Michel Lespinasse
     

30 May, 2012

1 commit

  • lglocks and brlocks are currently generated with some complicated macros
    in lglock.h. But there's no reason to not just use common utility
    functions and put all the data into a common data structure.

    Since there are at least two users it makes sense to share this code in a
    library. This is also easier maintainable than a macro forest.

    This will also make it later possible to dynamically allocate lglocks and
    also use them in modules (this would both still need some additional, but
    now straightforward, code)

    [akpm@linux-foundation.org: checkpatch fixes]
    Signed-off-by: Andi Kleen
    Cc: Al Viro
    Cc: Rusty Russell
    Signed-off-by: Andrew Morton
    Signed-off-by: Rusty Russell
    Signed-off-by: Al Viro

    Andi Kleen