This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [GIT PULL] for-2.6.32/bug-fixes

To: "Konrad Rzeszutek Wilk" <konrad.wilk@xxxxxxxxxx>
Subject: Re: [Xen-devel] [GIT PULL] for-2.6.32/bug-fixes
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Tue, 17 May 2011 11:07:05 +0100
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 17 May 2011 03:07:56 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4DD260700200007800041962@xxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20110516203535.GA871@xxxxxxxxxxxx> <4DD260700200007800041962@xxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> On 17.05.11 at 11:48, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:
>>>> On 16.05.11 at 22:35, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> wrote:
>> with xen-blkback wherein a barrier request would have been discarded (and an 
> error
>> returned) b/c the sector provided via the request was -1. The -1 sector made
>> vbd_translate return an error (it checked the sector number against the size 
> of
>> the disk) and it would never go through trying to do a barrier. The second 
> bug-fix
>> is also in my devel/xen-blkback-v3.2 upstream tree.
> Is this really correct? You appear to assume that BLKIF_OP_WRITE_BARRIER
> always has no data, but the rest of the code in the driver (and
> the frontend) doesn't seem to imply that (see e.g. the check
> immediately following the switch statement your patch modifies).
> Hence shouldn't you clear the sector number only when
> req->nr_segments is zero? Or alternatively, shouldn't
> vbd_translate() simply not fail when req->nr_sects is zero?
> Additionally, looking at the check in vbd_translate(), wouldn't you
> think there ought to be overflow checking for the addition, too?

Altogether e.g.

Subject: xen/blkback: don't fail empty barrier requests

The sector number on empty barrier requests may (will?) be -1, which,
given that it's being treated as unsigned 64-bit quantity, will almost
always exceed the actual (virtual) disk's size.

Inspired by Konrad's "When writting barriers set the sector number to

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

Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>

--- a/drivers/xen/blkback/vbd.c
+++ b/drivers/xen/blkback/vbd.c
@@ -114,8 +114,14 @@ int vbd_translate(struct phys_req *req, 
        if (vbd->bdev == NULL)
                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;

Xen-devel mailing list