> Isn't the 4.1 fix just:
>
> diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
> index e5befa356dbe..6e4350a78257 100644
> --- a/drivers/md/raid5.c
> +++ b/drivers/md/raid5.c
> @@ -3522,16 +3522,16 @@ returnbi:
> * no updated data, so remove it from hash list and the stripe
> * will be reinitialized
> */
> - spin_lock_irq(&conf->device_lock);
> unhash:
> + spin_lock_irq(conf->hash_locks + sh->hash_lock_index);
> remove_hash(sh);
> + spin_unlock_irq(conf->hash_locks + sh->hash_lock_index);
> if (head_sh->batch_head) {
> sh = list_first_entry(&sh->batch_list,
> struct stripe_head, batch_list);
> if (sh != head_sh)
> goto unhash;
> }
> - spin_unlock_irq(&conf->device_lock);
> sh = head_sh;
>
> if (test_bit(STRIPE_SYNC_REQUESTED, &sh->state))
>
> ??
In my opion, this patch looks correct, although it seems to me, that there is an another issue here.
> if (head_sh->batch_head) {
> sh = list_first_entry(&sh->batch_list,
> struct stripe_head, batch_list);
> if (sh != head_sh)
> goto unhash;
> }
With a patch above this code will be executed without taking any locks. It it correct?
In my opinion, we need to take at least sh->stripe_lock, which protects sh->batch_head.
Or do I miss something?
If you want, we can handle this issue separately.
Thanks,
Roman
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
