summaryrefslogtreecommitdiff
path: root/arch
diff options
context:
space:
mode:
authorNeilBrown <neilb@suse.de>2013-06-12 11:01:22 +1000
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2013-08-20 08:26:28 -0700
commit1b9203bb4c658c0242afa6fdb025c71d2fc3ad76 (patch)
tree1dfbea2025be2872abb7b435b630bce988b6e032 /arch
parentefb5fbe89cdcc97ce170bf53c0764d7d00b7a4a6 (diff)
md/raid1,raid10: use freeze_array in place of raise_barrier in various places.
commit e2d59925221cd562e07fee38ec8839f7209ae603 upstream. Various places in raid1 and raid10 are calling raise_barrier when they really should call freeze_array. The former is only intended to be called from "make_request". The later has extra checks for 'nr_queued' and makes a call to flush_pending_writes(), so it is safe to call it from within the management thread. Using raise_barrier will sometimes deadlock. Using freeze_array should not. As 'freeze_array' currently expects one request to be pending (in handle_read_error - the only previous caller), we need to pass it the number of pending requests (extra) to ignore. The deadlock was made particularly noticeable by commits 050b66152f87c7 (raid10) and 6b740b8d79252f13 (raid1) which appeared in 3.4, so the fix is appropriate for any -stable kernel since then. This patch probably won't apply directly to some early kernels and will need to be applied by hand. Cc: stable@vger.kernel.org Reported-by: Alexander Lyakas <alex.bolshoy@gmail.com> Signed-off-by: NeilBrown <neilb@suse.de> [adjust context to make it can be apply on top of 3.4 ] Signed-off-by: Jack Wang <jinpu.wang@profitbricks.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'arch')
0 files changed, 0 insertions, 0 deletions