git: HAMMER VFS - Major retooling of the refcount mechanics, and fix a deadlock

Matthew Dillon dillon at crater.dragonflybsd.org
Mon Mar 15 10:51:21 PDT 2010


commit 250aec18e447d7c9db30d4f905d21333e825a9d9
Author: Matthew Dillon <dillon at apollo.backplane.com>
Date:   Mon Mar 15 02:07:23 2010 -0700

    HAMMER VFS - Major retooling of the refcount mechanics, and fix a deadlock
    
    * Add an interlock to hammer_lock->refs which is independent of
      hammer_lock->lockval.
    
    * Retool the refcount mechanics to integrate the interlock on 0->1 and
      1->0 transitions.
    
      In addition implement a check bit to deal with serialization races
      between threads which forces all threads to interlock.  This deals
      with the case where one thread bumps the refcount (lock->refs) but
      is unable to immediateliy acquire the interlock.  Other threads doing
      the same thing will race and lock->refs will be bumped far higher
      than 1.  The check bit is set on the 0->1 transition and enforces
      all threads to serialize until one (usually the first to acquire the
      lock) is able to dispose of the check condition.
    
      The transition interlocks are used to do I/O loading and validation
      on the 0->N transition and I/O unloading and invalidation on the 1->0
      transition.
    
    * The new integrated mechanics also simplify hammer_io's handling of
      B_LOCKED slightly and properly interlocks changes in disposition for
      the related buffer cache buffer against refcount transitions.
    
    * The new integrated refcount/interlock is also more optimal as the
      combined operation can be done in a single atomic_cmpset_int() call,
      and fully MPSAFE.  Even though other major portions of HAMMER are not
      yet MPSAFE getting this particular bit dealt with will ease MP work
      later on.
    
    * Retool the volume, buffer, and node referencing code to use the new
      mechanics.  This fixes a deadlock.  These routines were previously
      acquiring an exclusive lock instead of an interlock.  The exclusive
      lock could combine with shared locks held by the same thread to create
      a deadlock situation against other threads.
    
      Use of the interlock fixes this particular deadlock.
    
    Reported-by: Francois Tigeot <ftigeot at wolfpond.org> (deadlock report)

Summary of changes:
 sys/vfs/hammer/hammer.h         |   62 ++++-
 sys/vfs/hammer/hammer_btree.c   |    6 +-
 sys/vfs/hammer/hammer_flusher.c |    8 -
 sys/vfs/hammer/hammer_inode.c   |   30 ++--
 sys/vfs/hammer/hammer_io.c      |   47 +++--
 sys/vfs/hammer/hammer_object.c  |    6 +-
 sys/vfs/hammer/hammer_ondisk.c  |  454 ++++++++++++++++++++++----------------
 sys/vfs/hammer/hammer_recover.c |   10 +-
 sys/vfs/hammer/hammer_subs.c    |  462 ++++++++++++++++++++++++++++++++++++---
 9 files changed, 803 insertions(+), 282 deletions(-)

http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/250aec18e447d7c9db30d4f905d21333e825a9d9


-- 
DragonFly BSD source repository





More information about the Commits mailing list