WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Re: [PATCH 3/3] xen-blkfront: If no barrier or flush is

To: Jan Beulich <JBeulich@xxxxxxxx>
Subject: Re: [Xen-devel] Re: [PATCH 3/3] xen-blkfront: If no barrier or flush is supported, use invalid operation.
From: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Date: Fri, 16 Sep 2011 15:15:15 -0400
Cc: axboe@xxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx, jeremy.fitzhardinge@xxxxxxxxxx, stable@xxxxxxxxxx
Delivery-date: Fri, 16 Sep 2011 12:16:38 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4E6DD8750200007800055ADA@xxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1315593060-20031-1-git-send-email-konrad.wilk@xxxxxxxxxx> <1315593060-20031-3-git-send-email-konrad.wilk@xxxxxxxxxx> <4E6DD8750200007800055ADA@xxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.21 (2010-09-15)
On Mon, Sep 12, 2011 at 09:01:25AM +0100, Jan Beulich wrote:
> >>> On 09.09.11 at 20:31, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> 
> >>> wrote:
> > By default we would set the info->flush_op=0, and zero maps
> > to BLKIF_OP_READ request code. So if the backend did not support
> > either barrier ('feature-barrier') or flush ('feature-flush-cache')
> > we would end up using that opcode for the flush/barrier request, meaning
> > we actually do a READ request. Fortunatly for us, __generic_make_request
> > checks q->flush_flags and realizes that we don't do FLUSH and removes
> > the REQ_FLUSH | REQ_FUA so we never end up issuing a READ request
> > for a flush request. However, other third party implementations of
> > __make_request might not be so smart, so lets fix this up.
> 
> Wouldn't it be better to simply have blkif_queue_request() fail in that
> case (and then it doesn't matter whether flush_op is set to 0 or -1)?
> Not the least because older (forward-port) backends stall the incoming
> queue and are possibly verbose for invalid requests seen.

So like this:


diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 468bfec..e9d301c 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -380,7 +380,9 @@ static void do_blkif_request(struct request_queue *rq)
 
                blk_start_request(req);
 
-               if (req->cmd_type != REQ_TYPE_FS) {
+               if ((req->cmd_type != REQ_TYPE_FS) ||
+                   ((req->cmd_flags & (REQ_FLUSH | REQ_FUA)) &&
+                   !info->flush_op)) {
                        __blk_end_request_all(req, -EIO);
                        continue;
                }

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel