xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Marek Marczykowski <marmarek@mimuw.edu.pl>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: blkfront problem in pvops kernel when barriers enabled
Date: Thu, 1 Dec 2011 14:08:13 -0500	[thread overview]
Message-ID: <20111201190813.GA10824@phenom.dumpdata.com> (raw)
In-Reply-To: <4E665572.7080009@mimuw.edu.pl>

On Tue, Sep 06, 2011 at 07:16:34PM +0200, Marek Marczykowski wrote:
> On 06.09.2011 18:32, Konrad Rzeszutek Wilk wrote:
> > On Sun, Sep 04, 2011 at 12:49:42PM +0200, Marek Marczykowski wrote:
> >> Hello,
> >>
> >> Pvops block frontend (tested vanilla 3.0.3, 3.1rc2, Konrad's testing
> >> branch) produces a lot of I/O errors when barriers are enabled but
> >> cannot be used.
> >>
> >> On xenlinux I've got message:
> >> [   15.036921] blkfront: xvdb: empty write barrier op failed
> >> [   15.036936] blkfront: xvdb: barriers disabled
> >>
> >> and after that, everything works fine. On pvops - I/O errors.
> >> As backend I've used 2.6.38.3 xenlinux (based on SUSE package) and
> >> 3.1rc2 with same result.
> > 
> > Hm, and the 'feature-barrier' was enabled on in those backends?
> > That is really bizzare considering that those backends don't actually
> > support WRITE_BARRIER anymore.
> 
> At least in 2.6.38.3 xenlinux  (SUSE). Now I'm not sure if 3.1rc2 also
> needed this modification (can't find it now).

I think this is resolved now? This patch below should fix the issue
(at least it did for me when I tried 3.0 with a 2.6.32 older backend
with DEBUG enabled):


# HG changeset patch
From: Jan Beulich <jbeulich@novell.com>
# Date 1306409621 -3600
# Node ID 876a5aaac0264cf38cae6581e5714b93ec380aaa
# Parent  aedb712c05cf065e943e15d0f38597c2e80f7982
Subject: xen/blkback: don't fail empty barrier requests

The sector number on empty barrier requests may (will?) be
uninitialized (neither bio_init() nor rq_init() set the respective
fields), which allows for exceeding the actual (virtual) disk's size.

Inspired by Konrad's "When writting barriers set the sector number to
zero...", but instead of zapping the sector number (which is wrong for
non-empty ones) just ignore the sector number when the sector count is
zero.

While at it also add overflow checking to the math in vbd_translate().

Signed-off-by: Jan Beulich <jbeulich@novell.com>

diff -r aedb712c05cf -r 876a5aaac026 drivers/xen/blkback/vbd.c
--- a/drivers/xen/blkback/vbd.c	Thu May 26 08:09:04 2011 +0100
+++ b/drivers/xen/blkback/vbd.c	Thu May 26 12:33:41 2011 +0100
@@ -108,8 +108,14 @@ int vbd_translate(struct phys_req *req, 
 	if ((operation != READ) && vbd->readonly)
 		goto out;
 
-	if (unlikely((req->sector_number + req->nr_sects) > vbd_sz(vbd)))
-		goto out;
+	if (likely(req->nr_sects)) {
+		blkif_sector_t end = req->sector_number + req->nr_sects;
+
+		if (unlikely(end < req->sector_number))
+			goto out;
+		if (unlikely(end > vbd_sz(vbd)))
+			goto out;
+	}
 
 	req->dev  = vbd->pdevice;
 	req->bdev = vbd->bdev;

      parent reply	other threads:[~2011-12-01 19:08 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-04 10:49 blkfront problem in pvops kernel when barriers enabled Marek Marczykowski
2011-09-06 16:32 ` Konrad Rzeszutek Wilk
2011-09-06 16:55   ` Konrad Rzeszutek Wilk
2011-09-06 17:47     ` Marek Marczykowski
2011-09-06 17:16   ` Marek Marczykowski
2011-09-07  1:47     ` Konrad Rzeszutek Wilk
2011-09-07  9:50       ` Jan Beulich
2011-09-07 10:19         ` Jan Beulich
2011-09-07 17:41           ` Konrad Rzeszutek Wilk
2011-09-08  8:06             ` Jan Beulich
2011-09-08 13:11               ` Konrad Rzeszutek Wilk
2011-09-07 17:34       ` Jeremy Fitzhardinge
2011-09-07 17:43         ` Konrad Rzeszutek Wilk
2011-09-07 18:58           ` Jeremy Fitzhardinge
2011-09-07 19:31             ` Konrad Rzeszutek Wilk
2011-12-01 19:08     ` Konrad Rzeszutek Wilk [this message]

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=20111201190813.GA10824@phenom.dumpdata.com \
    --to=konrad.wilk@oracle.com \
    --cc=marmarek@mimuw.edu.pl \
    --cc=xen-devel@lists.xensource.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).