All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laszlo Ersek <lersek@redhat.com>
To: Vitaly Kuznetsov <vkuznets@redhat.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>,
	David Vrabel <david.vrabel@citrix.com>,
	xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org,
	Jeff Moyer <jmoyer@redhat.com>, Andrew Jones <drjones@redhat.com>
Subject: Re: [PATCH] xen/blkfront: improve protection against issuing unsupported REQ_FUA
Date: Mon, 03 Nov 2014 13:22:00 +0100	[thread overview]
Message-ID: <54577368.9060000@redhat.com> (raw)
In-Reply-To: <1414417478-20268-1-git-send-email-vkuznets@redhat.com>

On 10/27/14 14:44, Vitaly Kuznetsov wrote:
> Guard against issuing unsupported REQ_FUA and REQ_FLUSH was introduced
> in d11e61583 and was factored out into blkif_request_flush_valid() in
> 0f1ca65ee. However:
> 1) This check in incomplete. In case we negotiated to feature_flush = REQ_FLUSH
>    and flush_op = BLKIF_OP_FLUSH_DISKCACHE (so FUA is unsupported) FUA request
>    will still pass the check.
> 2) blkif_request_flush_valid() is misnamed. It is bool but returns true when
>    the request is invalid.
> 3) When blkif_request_flush_valid() fails -EIO is being returned. It seems that
>    -EOPNOTSUPP is more appropriate here.
> Fix all of the above issues.
> 
> This patch is based on the original patch by Laszlo Ersek and a comment by
> Jeff Moyer.
> 
> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
> ---
>  drivers/block/xen-blkfront.c | 14 ++++++++------
>  1 file changed, 8 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 5ac312f..2e6c103 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -582,12 +582,14 @@ static inline void flush_requests(struct blkfront_info *info)
>  		notify_remote_via_irq(info->irq);
>  }
>  
> -static inline bool blkif_request_flush_valid(struct request *req,
> -					     struct blkfront_info *info)
> +static inline bool blkif_request_flush_invalid(struct request *req,
> +					       struct blkfront_info *info)
>  {
>  	return ((req->cmd_type != REQ_TYPE_FS) ||
> -		((req->cmd_flags & (REQ_FLUSH | REQ_FUA)) &&
> -		!info->flush_op));
> +		((req->cmd_flags & REQ_FLUSH) &&
> +		 !(info->feature_flush & REQ_FLUSH)) ||
> +		((req->cmd_flags & REQ_FUA) &&
> +		 !(info->feature_flush & REQ_FUA)));
>  }
>  
>  /*
> @@ -612,8 +614,8 @@ static void do_blkif_request(struct request_queue *rq)
>  
>  		blk_start_request(req);
>  
> -		if (blkif_request_flush_valid(req, info)) {
> -			__blk_end_request_all(req, -EIO);
> +		if (blkif_request_flush_invalid(req, info)) {
> +			__blk_end_request_all(req, -EOPNOTSUPP);
>  			continue;
>  		}
>  
> 

Not sure if there has been some feedback yet (I can't see anything
threaded with this message in my inbox).

FWIW I consulted "Documentation/block/writeback_cache_control.txt" for
this review. Apparently, REQ_FLUSH forces out "previously completed
write requests", whereas REQ_FUA delays the IO completion signal for
*this* request until "the data has been committed to non-volatile
storage". So, indeed, support for REQ_FLUSH only does not guarantee that
REQ_FUA can be served.

Reviewed-by: Laszlo Ersek <lersek@redhat.com>

Thanks
Laszlo

  reply	other threads:[~2014-11-03 12:22 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-27 13:44 [PATCH] xen/blkfront: improve protection against issuing unsupported REQ_FUA Vitaly Kuznetsov
2014-11-03 12:22 ` Laszlo Ersek [this message]
2014-11-03 15:49   ` Boris Ostrovsky
2014-11-03 17:11     ` Vitaly Kuznetsov
2014-11-03 17:11     ` Vitaly Kuznetsov
2014-11-03 15:49   ` Boris Ostrovsky
2014-11-03 12:22 ` Laszlo Ersek
2014-12-01 13:01 ` [PATCH RESEND] " Vitaly Kuznetsov
2014-12-03 16:57   ` Boris Ostrovsky
2014-12-03 16:57   ` Boris Ostrovsky
2014-12-03 17:05     ` Vitaly Kuznetsov
2014-12-03 17:05     ` Vitaly Kuznetsov
2014-12-01 13:01 ` Vitaly Kuznetsov
  -- strict thread matches above, loose matches on Subject: below --
2014-10-27 13:44 [PATCH] " Vitaly Kuznetsov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54577368.9060000@redhat.com \
    --to=lersek@redhat.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=david.vrabel@citrix.com \
    --cc=drjones@redhat.com \
    --cc=jmoyer@redhat.com \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vkuznets@redhat.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.