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 17:24:43 +0100	[thread overview]
Message-ID: <4DD2BD6B0200007800041B40@vpn.id2.novell.com> (raw)
In-Reply-To: <20110517155746.GB3657@dumpdata.com>

>>> On 17.05.11 at 17:57, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
>> > 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.
> 
> OK, even if the code that actually does the bio submission does
> not attach any data to the bio? The end result is the same - no
> data with barriers.

My problem is that I can't see where attaching data would be
skipped. The only thing I see is the BUG_ON() you pointed at
earlier, checking that if there is no data, then this must be a
barrier request.

>> >> 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.
> 
> I concur. The value that is passed by the frontend is not zero. It is -1.

Oh, you say both sector_number and nr_sects are -1? Looking
again... No, that can't be the case, the value starts out at zero
in dispatch_rw_block_io().

Jan

  reply	other threads:[~2011-05-17 16:24 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
2011-05-17 15:57       ` Konrad Rzeszutek Wilk
2011-05-17 16:24         ` Jan Beulich [this message]
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=4DD2BD6B0200007800041B40@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).