Messages in this thread | | | From | Roman Gushchin <> | Subject | Re: [PATCH] md/raid5: fix locking in handle_stripe_clean_event() | Date | Fri, 30 Oct 2015 17:02:47 +0300 |
| |
> 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
| |