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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 16.09.11 at 21:15, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> wrote:
> 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:

Yes, this looks small and neat.

Acked-by: Jan Beulich <jbeulich@xxxxxxxx>

> 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