From owner-freebsd-xen@FreeBSD.ORG Wed Sep 4 18:03:55 2013 Return-Path: Delivered-To: freebsd-xen@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 88A7FF2B; Wed, 4 Sep 2013 18:03:55 +0000 (UTC) (envelope-from roger.pau@citrix.com) Received: from SMTP.EU.CITRIX.COM (smtp.eu.citrix.com [46.33.159.39]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C5A2028BE; Wed, 4 Sep 2013 18:03:54 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.89,1022,1367971200"; d="scan'208";a="8430211" Received: from lonpmailmx01.citrite.net ([10.30.203.162]) by LONPIPO01.EU.CITRIX.COM with ESMTP/TLS/RC4-MD5; 04 Sep 2013 18:03:51 +0000 Received: from [172.16.1.30] (10.68.19.166) by LONPMAILMX01.citrite.net (10.30.203.162) with Microsoft SMTP Server id 8.3.298.1; Wed, 4 Sep 2013 19:03:50 +0100 Message-ID: <52277605.3050204@citrix.com> Date: Wed, 4 Sep 2013 20:03:49 +0200 From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Justin T. Gibbs" Subject: Re: Another blkback issue related to flush References: <522768EA.6010809@citrix.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Cc: "freebsd-xen@freebsd.org" X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 18:03:55 -0000 On 04/09/13 19:49, Justin T. Gibbs wrote: > On Sep 4, 2013, at 11:07 AM, Roger Pau Monné wrote: > >> Hello, >> >> I've found another issue with blkback handling of flush operations, it >> was incorrectly setting one of the bio parameters when using a block >> device as backend. The attached patch fixes it, and also includes a >> small fix to correctly set the operation when writing the response on >> the ring (all responses written by FreeBSD blkback were of type >> BLKIF_OP_READ, because nreq->operation was not set). > > It seems that the req's pendcnt is unused and can be culled. Otherwise, > looks good to me. Here's the patch I have in my tree now. Thanks for catching this one. The patch looks OK to me.