Re: [PATCH RFC] md/raid1: fix deadlock between freeze_array() and wait_barrier().

[NeilBrown <neilb@suse.com>]

[-- Attachment #1: Type: text/plain, Size: 1261 bytes --]

On Mon, Jun 27 2016, Alexander Lyakas wrote:

> When we call wait_barrier, we might have some bios waiting
> in current->bio_list, which prevents the array_freeze call to
> complete. Those can only be internal READs, which have already
> passed the wait_barrier call (thus incrementing nr_pending), but
> still were not submitted to the lower level, due to generic_make_request
> logic to avoid recursive calls. In such case, we have a deadlock:
> - array_frozen is already set to 1, so wait_barrier unconditionally waits, so
> - internal READ bios will not be submitted, thus freeze_array will
> never completes
>
> This problem was originally fixed in commit:
> d6b42dc md/raid1,raid10: avoid deadlock during resync/recovery.
>
> But then it was broken in commit:
> b364e3d raid1: Add a field array_frozen to indicate whether raid in
> freeze state.

Thanks for the great analysis.
I think this primarily a problem in generic_make_request().  It queues
requests in the *wrong* order.

Please try the patch from
  https://lkml.org/lkml/2016/7/7/428

and see if it helps.  If two requests for a raid1 are in the
generic_make_request queue, this patch causes the sub-requests created
by the first to be handled before the second is attempted.

Thanks,
NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]