From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [GIT PULL] for-2.6.32/bug-fixes Date: Wed, 18 May 2011 10:56:44 -0400 Message-ID: <20110518145644.GA4556@dumpdata.com> References: <4DD373C0020000780007014D@vpn.id2.novell.com> <20110518132442.GB3238@dumpdata.com> <4DD3F4670200007800041E55@vpn.id2.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <4DD3F4670200007800041E55@vpn.id2.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jan Beulich Cc: jeremy@goop.org, xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On Wed, May 18, 2011 at 03:31:35PM +0100, Jan Beulich wrote: > >>> On 18.05.11 at 15:24, Konrad Rzeszutek Wilk wrote: > >> >Well, req->ns_segments = 0, so nseg is zero, which means all > >> >of those for loops never get executed. > >> > >> This you say is the case for the request you saw the failure with, or > >> *all* barrier requests? In the latter case, what do you conclude this > > > > Good question. It was the first barrier request sent when guest tried to > > mount the filesystem. I will instrument the code to see what the other > > barriers contained when they were sent. > > That wouldn't tell you anything if they're all empty, as there's nothing > preventing other guests (including other guest OSes) to still send > non-empty ones - after all the protocol allows for this. Aha! That is what you been trying to tell me. I will make a patch to make sure to not overwrite the req->sector_number blindly. What other guest OSes use barriers? I looked at Solaris (it uses 'feature-flush-cache'), NetBSD ('feature-flush-cache') and Linux ('feature-barrier' and now in 2.6.40 'feature-flush-cache'). The GPLV Windows drivers have no barrier implementation - do you know if the Novell ones are using barriers?