From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bill Davidsen Subject: Re: [BUG] Raid5 trouble Date: Thu, 18 Oct 2007 22:55:46 -0400 Message-ID: <47181CB2.1060602@tmr.com> References: <4714BB92.7040701@systella.fr> <47161CE3.80909@systella.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: linux-raid-owner@vger.kernel.org To: Dan Williams Cc: =?ISO-8859-1?Q?BERTRAND_Jo=EBl?= , linux-raid@vger.kernel.org, sparclinux@vger.kernel.org List-Id: linux-raid.ids Dan Williams wrote: > I found a problem which may lead to the operations count dropping > below zero. If ops_complete_biofill() gets preempted in between the > following calls: > > raid5.c:554> clear_bit(STRIPE_OP_BIOFILL, &sh->ops.ack); > raid5.c:555> clear_bit(STRIPE_OP_BIOFILL, &sh->ops.pending); > > ...then get_stripe_work() can recount/re-acknowledge STRIPE_OP_BIOFILL > causing the assertion. In fact, the 'pending' bit should always be > cleared first, but the other cases are protected by > spin_lock(&sh->lock). Patch attached. > Once this patch has been vetted, can it be offered to -stable for 2.6.23? Or to be pedantic, it *can*, will you make that happen? -- bill davidsen CTO TMR Associates, Inc Doing interesting things with small computers since 1979