md/raid1,raid10: use freeze_array in place of raise_barrier in various places.
authorNeilBrown <neilb@suse.de>
Wed, 12 Jun 2013 01:01:22 +0000 (11:01 +1000)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Tue, 20 Aug 2013 15:26:28 +0000 (08:26 -0700)
commit1b9203bb4c658c0242afa6fdb025c71d2fc3ad76
tree1dfbea2025be2872abb7b435b630bce988b6e032
parentefb5fbe89cdcc97ce170bf53c0764d7d00b7a4a6
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>
drivers/md/raid1.c
drivers/md/raid10.c