xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: "Jan Beulich" <JBeulich@novell.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>, xen-devel@lists.xensource.com
Subject: Re: [GIT PULL] for-2.6.32/bug-fixes
Date: Tue, 17 May 2011 16:06:00 +0100	[thread overview]
Message-ID: <4DD2AAF80200007800041AC9@vpn.id2.novell.com> (raw)
In-Reply-To: <20110517141629.GC6816@dumpdata.com>

>>> On 17.05.11 at 16:16, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> 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@oracle.com> 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.

Sure, this direction we agree about. But your change is enforcing
it the other way around (if barrier then no data), which wasn't the
case so far.

>> 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.

Hmm, depends on your perspective - I'd say that any sector_number
is valid when nr_sects is zero.

Jan

  reply	other threads:[~2011-05-17 15:06 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-16 20:35 [GIT PULL] for-2.6.32/bug-fixes Konrad Rzeszutek Wilk
2011-05-17  9:48 ` Jan Beulich
2011-05-17 10:07   ` Jan Beulich
2011-05-17 14:16   ` Konrad Rzeszutek Wilk
2011-05-17 15:06     ` Jan Beulich [this message]
2011-05-17 15:57       ` Konrad Rzeszutek Wilk
2011-05-17 16:24         ` Jan Beulich
2011-05-17 16:43           ` Konrad Rzeszutek Wilk
  -- strict thread matches above, loose matches on Subject: below --
2011-05-18  6:22 Jan Beulich
2011-05-18 13:24 ` Konrad Rzeszutek Wilk
2011-05-18 14:31   ` Jan Beulich
2011-05-18 14:56     ` Konrad Rzeszutek Wilk
2011-05-18 15:03       ` Jan Beulich
2011-05-18 15:13         ` Konrad Rzeszutek Wilk
2011-05-18 15:23           ` Jan Beulich
2011-01-27 18:52 Konrad Rzeszutek Wilk

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=4DD2AAF80200007800041AC9@vpn.id2.novell.com \
    --to=jbeulich@novell.com \
    --cc=jeremy@goop.org \
    --cc=konrad.wilk@oracle.com \
    --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).