md/raid5: fix newly-broken locking in get_active_stripe.
authorNeilBrown <neilb@suse.de>
Wed, 27 Nov 2013 23:55:27 +0000 (10:55 +1100)
committerNeilBrown <neilb@suse.de>
Thu, 28 Nov 2013 00:00:15 +0000 (11:00 +1100)
commit6d183de4077191d1201283a9035ce57a9b05254d
tree2fcae1c346ab7cdb7c9cd3c45f78596d3876017f
parent142d44c310819e1965ca70b4d55d7679f5797e25
md/raid5: fix newly-broken locking in get_active_stripe.

commit 566c09c53455d7c4f1 raid5: relieve lock contention in get_active_stripe()

modified the locking in get_active_stripe() reducing the range
protected by the (highly contended) device_lock.
Unfortunately it reduced the range too much opening up some races.

One race can occur if get_priority_stripe runs between the
test on sh->count and device_lock being taken.
This will mean that sh->lru is not empty while get_active_stripe
thinks ->count is zero resulting in a 'BUG' firing.

Another race happens if __release_stripe is called immediately
after sh->count is tested and found to be non-zero.  If STRIPE_HANDLE
is not set, get_active_stripe should increment ->active_stripes
when it increments ->count from 0, but as it didn't think it was 0,
it doesn't.

Extending device_lock to cover the test on sh->count close these
races.

While we are here, fix the two BUG tests:
 -If count is zero, then lru really must not be empty, or we've
  lock the stripe_head somehow - no other tests are relevant.
 -STRIPE_ON_RELEASE_LIST is completely independent of ->lru so
  testing it is pointless.

Reported-and-tested-by: Brassow Jonathan <jbrassow@redhat.com>
Reviewed-by: Shaohua Li <shli@kernel.org>
Fixes: 566c09c53455d7c4f1
Signed-off-by: NeilBrown <neilb@suse.de>
drivers/md/raid5.c