summaryrefslogtreecommitdiff
path: root/drivers/tty
diff options
context:
space:
mode:
authorRoman Gushchin <klamm@yandex-team.ru>2015-10-31 02:53:50 +0300
committerSasha Levin <sasha.levin@oracle.com>2015-11-15 20:51:53 +0300
commit0ac9586cd0477c6ed1e4bb6c9b0b18503e25f6f5 (patch)
tree1e135cce0d8882cb49c98ce756f3040529e7c447 /drivers/tty
parent69a7ca06041ad6f3a7672db472ac26cdd2a3df83 (diff)
downloadlinux-0ac9586cd0477c6ed1e4bb6c9b0b18503e25f6f5.tar.xz
md/raid5: fix locking in handle_stripe_clean_event()
[ Upstream commit b8a9d66d043ffac116100775a469f05f5158c16f ] 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> Cc: <stable@vger.kernel.org> # 3.13 - 4.2 Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Diffstat (limited to 'drivers/tty')
0 files changed, 0 insertions, 0 deletions