WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Jan Beulich <JBeulich@xxxxxxxxxx>
Subject: Re: [Xen-devel] [GIT PULL] for-2.6.32/bug-fixes
From: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Date: Tue, 17 May 2011 10:16:29 -0400
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 17 May 2011 07:17:22 -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
User-agent: Mutt/1.5.21 (2010-09-15)
On Tue, May 17, 2011 at 10:48:00AM +0100, Jan Beulich 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).

That is correct. Look at the end of the code logic (this is from the 2.6.18
hg tree):

528         if (!bio) {
529                 BUG_ON(operation != WRITE_BARRIER);
530                 bio = bio_alloc(GFP_KERNEL, 0);
531                 if (unlikely(bio == NULL))
532                         goto fail_put_bio;
533 
534                 bio->bi_bdev    = preq.bdev;
535                 bio->bi_private = pending_req;
536                 bio->bi_end_io  = end_block_io_op;
537                 bio->bi_sector  = -1;
538         }

No attaching of data to the barrier.

> Hence shouldn't you clear the sector number only when
> req->nr_segments is zero? Or alternatively, shouldn't

We could do that too.

> vbd_translate() simply not fail when req->nr_sects is zero?

It does not fail when req->nr_sects is zero. It fails when it is -1.

> 
> Additionally, looking at the check in vbd_translate(), wouldn't you
> think there ought to be overflow checking for the addition, too?

Sure, could add that in. Albeit it seems incorrect to do it in that
function. It checks to see if the sector is correct, and -1 is definitly
wrong.

> 
> Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel