Re: [Xen-devel] Re: [PATCH 3/3] xen-blkfront: If no barrier or flush is supported, use invalid operation.

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

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