Patch "md/raid5: fix locking in handle_stripe_clean_event()" has been added to the 3.14-stable tree
Subsystems (2)
This is a note to let you know that I've just added the patch titled
md/raid5: fix locking in handle_stripe_clean_event()
to the 3.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
md-raid5-fix-locking-in-handle_stripe_clean_event.patch
and it can be found in the queue-3.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree, please let <[email protected]> know about it.
Quoted 1 line
From
b8a9d66d043ffac116100775a469f05f5158c16fMon Sep 17 00:00:00 2001
From: Roman Gushchin <[email protected]>
Date: Sat, 31 Oct 2015 10:53:50 +1100
Subject: md/raid5: fix locking in handle_stripe_clean_event()
From: Roman Gushchin <[email protected]>
commit b8a9d66d043ffac116100775a469f05f5158c16f upstream.
After commit 566c09c53455 ("raid5: relieve lock contention in get_active_stripe()") __find_stripe() is called under conf->hash_locks + hash.
But handle_stripe_clean_event() calls remove_hash() under conf->device_lock.
Under some cirscumstances the hash chain can be circuited, and we get an infinite loop with disabled interrupts and locked hash lock in __find_stripe(). This leads to hard lockup on multiple CPUs and following system crash.
I was able to reproduce this behavior on raid6 over 6 ssd disks. The devices_handle_discard_safely option should be set to enable trim support. The following script was used:
for i in seq 1 32; do
dd if=/dev/zero of=large$i bs=10M count=100 &
done
neilb: original was against a 3.x kernel. I forward-ported
to 4.3-rc. This verison is suitable for any kernel since
Commit: 59fc630b8b5f ("RAID5: batch adjacent full stripe write") (v4.1+). I'll post a version for earlier kernels to stable.
--- drivers/md/raid5.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/md/raid5.c +4 -2
@@ -3029,6 +3029,8 @@ static void handle_stripe_clean_event(st }if (!discard_pending &&test_bit (R5_Discard, &sh->dev[sh->pd_idx].flags)) { +int hash = sh->hash_lock_index; +clear_bit (R5_Discard, &sh->dev[sh->pd_idx].flags);clear_bit (R5_UPTODATE , &sh->dev[sh->pd_idx].flags);if (sh->qd_idx >=0 ) {
@@ -3042,9 +3044,9 @@ static void handle_stripe_clean_event(st* no updated data, so remove it from hash list and the stripe * will be reinitialized */ -spin_lock_irq (&conf->device_lock); +spin_lock_irq (conf->hash_locks + hash);remove_hash (sh); -spin_unlock_irq (&conf->device_lock); +spin_unlock_irq (conf->hash_locks + hash);if (test_bit (STRIPE_SYNC_REQUESTED , &sh->state))set_bit (STRIPE_HANDLE , &sh->state);
Patches currently in stable-queue which might be from [email protected] are
queue-3.14/md-raid5-fix-locking-in-handle_stripe_clean_event.patch