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
next prev parent 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.