From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966323AbbJ3OCx (ORCPT ); Fri, 30 Oct 2015 10:02:53 -0400 Received: from forward-corp1m.cmail.yandex.net ([5.255.216.100]:60824 "EHLO forward-corp1m.cmail.yandex.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966169AbbJ3OCv (ORCPT ); Fri, 30 Oct 2015 10:02:51 -0400 From: Roman Gushchin To: Neil Brown , "linux-kernel@vger.kernel.org" Cc: Shaohua Li , "linux-raid@vger.kernel.org" In-Reply-To: <87ziz1w33r.fsf@notabene.neil.brown.name> References: <1446022340-1453-1-git-send-email-klamm@yandex-team.ru> <87r3kebjgx.fsf@notabene.neil.brown.name> <30651446128148@webcorp02d.yandex-team.ru> <87ziz1w33r.fsf@notabene.neil.brown.name> Subject: Re: [PATCH] md/raid5: fix locking in handle_stripe_clean_event() MIME-Version: 1.0 Message-Id: <47541446213767@webcorp02e.yandex-team.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Fri, 30 Oct 2015 17:02:47 +0300 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=koi8-r Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > 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