aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm
diff options
context:
space:
mode:
authorNeilBrown <neilb@suse.de>2012-03-19 12:46:38 +1100
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2012-04-02 09:27:11 -0700
commit4db1aef6a2b79aba4f862285c2658348e083f2b7 (patch)
tree99a17e4a91617491a6f431c3efab4ce50fb4db98 /drivers/gpu/drm
parent6990597d9d2f45a969d16d068369f93db0a7d281 (diff)
downloadkernel_samsung_crespo-4db1aef6a2b79aba4f862285c2658348e083f2b7.zip
kernel_samsung_crespo-4db1aef6a2b79aba4f862285c2658348e083f2b7.tar.gz
kernel_samsung_crespo-4db1aef6a2b79aba4f862285c2658348e083f2b7.tar.bz2
md/raid1,raid10: avoid deadlock during resync/recovery.
commit d6b42dcb995e6acd7cc276774e751ffc9f0ef4bf upstream. If RAID1 or RAID10 is used under LVM or some other stacking block device, it is possible to enter a deadlock during resync or recovery. This can happen if the upper level block device creates two requests to the RAID1 or RAID10. The first request gets processed, blocks recovery and queue requests for underlying requests in current->bio_list. A resync request then starts which will wait for those requests and block new IO. But then the second request to the RAID1/10 will be attempted and it cannot progress until the resync request completes, which cannot progress until the underlying device requests complete, which are on a queue behind that second request. So allow that second request to proceed even though there is a resync request about to start. This is suitable for any -stable kernel. Reported-by: Ray Morris <support@bettercgi.com> Tested-by: Ray Morris <support@bettercgi.com> Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'drivers/gpu/drm')
0 files changed, 0 insertions, 0 deletions