Skip to content

L
linux
Switch branch/tag
  1. 12 Aug, 2009 1 commit
    • NeilBrown's avatar
      md: never advance 'events' counter by more than 1. · 51d5668c
      NeilBrown authored 
      When assembling arrays, md allows two devices to have different event
counts as long as the difference is only '1'.  This is to cope with
a system failure between updating the metadata on two difference
devices.

However there are currently times when we update the event count by
2.  This was done to keep the event count even when the array is clean
and odd when it is dirty, which allows us to avoid writing common
update to spare devices and so allow those spares to go to sleep.

This is bad for the above reason.  So change it to never increase by
two.  This means that the alignment between 'odd/even' and
'clean/dirty' might take a little longer to attain, but that is only a
small cost.  The spares will get a few more updates but that will
still be spared (;-) most updates and can still go to sleep.

Prior to this patch there was a small chance that after a crash an
array would fail to assemble due to the overly large event count
mismatch.
Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      51d5668c
  3. 10 Aug, 2009 1 commit
    • 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 d63a5a74Reported-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
  5. 08 Aug, 2009 5 commits
  7. 07 Aug, 2009 33 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7