Skip to content
  1. Aug 10, 2009
    • NeilBrown's avatar
      Remove deadlock potential in md_open · c8c00a69
      NeilBrown authored
      
      
      A recent commit:
        commit 449aad3e
      
      introduced the possibility of an A-B/B-A deadlock between
      bd_mutex and reconfig_mutex.
      
      __blkdev_get holds bd_mutex while calling md_open which takes
         reconfig_mutex,
      do_md_run is always called with reconfig_mutex held, and it now
         takes bd_mutex in the call the revalidate_disk.
      
      This potential deadlock was not caught by lockdep due to the
      use of mutex_lock_interruptible_nexted which was introduced
      by
         commit d63a5a74
      do avoid a warning of an impossible deadlock.
      
      It is quite possible to split reconfig_mutex in to two locks.
      One protects the array data structures while it is being
      reconfigured, the other ensures that an array is never even partially
      open while it is being deactivated.
      In particular, the second lock prevents an open from completing
      between the time when do_md_stop checks if there are any active opens,
      and the time when the array is either set read-only, or when ->pers is
      set to NULL.  So we can be certain that no IO is in flight as the
      array is being destroyed.
      
      So create a new lock, open_mutex, just to ensure exclusion between
      'open' and 'stop'.
      
      This avoids the deadlock and also avoids the lockdep warning mentioned
      in commit d63a5a74
      
      Reported-by: default avatar"Mike Snitzer" <snitzer@gmail.com>
      Reported-by: default avatar"H. Peter Anvin" <hpa@zytor.com>
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      c8c00a69
  2. Aug 08, 2009