qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Avi Kivity <avi@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: Michael Tokarev <mjt@tls.msk.ru>,
	qemu-devel@nongnu.org, Christoph Hellwig <hch@lst.de>
Subject: Re: [Qemu-devel] Re: [PATCH] block: fix sector comparism in multiwrite_req_compare
Date: Thu, 20 May 2010 11:30:44 +0300	[thread overview]
Message-ID: <4BF4F334.2010506@redhat.com> (raw)
In-Reply-To: <4BF4F0A4.3010304@redhat.com>

On 05/20/2010 11:19 AM, Kevin Wolf wrote:
> Am 20.05.2010 08:09, schrieb Avi Kivity:
>    
>> On 05/20/2010 12:09 AM, Kevin Wolf wrote:
>>      
>>>        
>>>> Actually it's not that obvious.  If the actual problem
>>>> here (besides the mis-comparison) is due to missing
>>>> barriers or flushes.  Avi asked a good question in that
>>>> thread.
>>>>
>>>>          
>>> It's obvious that it's a hack. It doesn't fix anything, it just disables a
>>> feature that didn't work. Good for debugging, but not something that you
>>> would like to commit.
>>>
>>> It's reasonable to include something like this when we know that something is
>>> broken but we haven't found it yet - but I believe Christoph's patch is the
>>> real fix. If anyone can still find a case that is "fixed" by Avi's patch, I
>>> could be convinced to apply it anyway, but I'd prefer if I didn't have to.
>>>
>>> Note that we actually don't have overlapping requests. It just looks like it
>>> because the qsort call doesn't work correctly with the broken comparison
>>> function, so lower sector numbers can come after higher ones.
>>>
>>>        
>> I agree my patch didn't fix the problem, only made it disappear, but
>> won't the current code break with overlapping requests?
>>      
> Maybe --verbose for your patch descriptions would help. I didn't see any
> obvious problem. If you know any, care to explain?
>    

Looking again, you are right.  There is code to take care of the 
overlap, and even a comment.  So my patch is indeed bogus.

>             size_t size;
>             QEMUIOVector *qiov = qemu_mallocz(sizeof(*qiov));
>             qemu_iovec_init(qiov,
>                 reqs[outidx].qiov->niov + reqs[i].qiov->niov + 1);
>
>             // Add the first request to the merged one. If the 
> requests are
>             // overlapping, drop the last sectors of the first request.
>             size = (reqs[i].sector - reqs[outidx].sector) << 9;
>             qemu_iovec_concat(qiov, reqs[outidx].qiov, size);

size can overflow on 32-bit.

Unrelated issue:  it seems we read the request directly from guest 
memory.  Since we access it multiple times, the guest can play with the 
contents meanwhile, invalidating previous decisions.  Shouldn't we copy 
all non-data elements to private storage?

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

  reply	other threads:[~2010-05-20  8:31 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-19 18:53 [Qemu-devel] [PATCH] block: fix sector comparism in multiwrite_req_compare Christoph Hellwig
2010-05-19 19:26 ` [Qemu-devel] " Michael Tokarev
2010-05-19 19:38   ` Christoph Hellwig
2010-05-19 19:42     ` Michael Tokarev
2010-05-19 21:09       ` Kevin Wolf
2010-05-20  6:09         ` Avi Kivity
2010-05-20  8:19           ` Kevin Wolf
2010-05-20  8:30             ` Avi Kivity [this message]
2010-05-20  8:50 ` Kevin Wolf

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=4BF4F334.2010506@redhat.com \
    --to=avi@redhat.com \
    --cc=hch@lst.de \
    --cc=kwolf@redhat.com \
    --cc=mjt@tls.msk.ru \
    --cc=qemu-devel@nongnu.org \
    /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).