[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: [PATCH] block: fix sector comparism in multiwrite_r

From: Avi Kivity
Subject: Re: [Qemu-devel] Re: [PATCH] block: fix sector comparism in multiwrite_req_compare
Date: Thu, 20 May 2010 11:30:44 +0300
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4

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

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));
                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 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]