]> www.infradead.org Git - users/jedix/linux-maple.git/commit
md/raid5: fix locking in handle_stripe_clean_event()
authorRoman Gushchin <klamm@yandex-team.ru>
Fri, 30 Oct 2015 23:53:50 +0000 (10:53 +1100)
committerChuck Anderson <chuck.anderson@oracle.com>
Fri, 5 Feb 2016 03:28:27 +0000 (19:28 -0800)
commit583e6c2036b1f83338fd425fcab2309ee89c36bd
treebd68060e61ccf15972667334bdfbef01d98bd995
parent3f2189fc2be65e8f3fc032d039cd8d7b5e9a7631
md/raid5: fix locking in handle_stripe_clean_event()

Orabug: 22623823

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.

Signed-off-by: Roman Gushchin <klamm@yandex-team.ru>
Fixes: 566c09c53455 ("raid5: relieve lock contention in get_active_stripe()")
Signed-off-by: NeilBrown <neilb@suse.com>
Cc: Shaohua Li <shli@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit a89e9e234a84bf9a67586f57f4e027c880439383)
Signed-off-by: Dan Duval <dan.duval@oracle.com>
drivers/md/raid5.c