Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753221AbZK0EP5 (ORCPT ); Thu, 26 Nov 2009 23:15:57 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753089AbZK0EP4 (ORCPT ); Thu, 26 Nov 2009 23:15:56 -0500 Received: from cantor2.suse.de ([195.135.220.15]:48883 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753024AbZK0EPt (ORCPT ); Thu, 26 Nov 2009 23:15:49 -0500 Date: Fri, 27 Nov 2009 15:17:21 +1100 From: Neil Brown To: Jiri Slaby Cc: James Bottomley , linux-kernel@vger.kernel.org, akpm@linux-foundation.org, mm-commits@vger.kernel.org, linux-scsi@vger.kernel.org, Jens Axboe Subject: Re: BUG at scsi_lib.c:1108 [Was: mmotm 2009-11-24-16-47 uploaded] Message-ID: <20091127151721.57c02c29@notabene.brown> In-Reply-To: <20091126081359.414c8216@notabene.brown> References: <200911250111.nAP1BFg5030254@imap1.linux-foundation.org> <4B0D4949.4090109@gmail.com> <1259162399.2535.8.camel@mulgrave.site> <4B0D9221.2050103@gmail.com> <20091126081359.414c8216@notabene.brown> X-Mailer: Claws Mail 3.7.2 (GTK+ 2.18.1; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1395 Lines: 38 On Thu, 26 Nov 2009 08:13:59 +1100 Neil Brown wrote: > On Wed, 25 Nov 2009 21:22:57 +0100 > Jiri Slaby wrote: > > > It doesn't make sense at all. How can empty merge cause a regression? > > And md/for-next doesn't produce the BUG. > > I've hit that situation before. Two separate changes in separate > branches conspire to cause a problem. > > md/for-next contains code to handle barriers properly for all levels, > not just RAID1. > It is possible I got this wrong in some way, and some new sanity check > in a separate branch is firing, or it is possible some other bug in > barrier handling has been added and now that MD sends barriers, it is > being triggered. And it looks like I did get it wrong in some way. I handled a barrier by: - send an empty barrier to each component - schedule to write with the barrier flag cleared - send another empty barrier If an empty barrier is received, step 2 sends an empty non-barrier, which caused the BUG. I have revised the code to special case empty barriers and only perform the first step. This should appear in the next -next. Thanks, NeilBrown -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/