qemu-block
[Top][All Lists]
Advanced

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

Re: [Qemu-block] [Qemu-devel] [PATCH v2 1/6] block: Fragment reads to ma


From: Eric Blake
Subject: Re: [Qemu-block] [Qemu-devel] [PATCH v2 1/6] block: Fragment reads to max transfer length
Date: Fri, 15 Jul 2016 08:28:53 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

On 07/14/2016 10:08 PM, Eric Blake wrote:
> On 07/08/2016 04:35 PM, Eric Blake wrote:
>> Drivers should be able to rely on the block layer honoring the
>> max transfer length, rather than needing to return -EINVAL
>> (iscsi) or manually fragment things (nbd).  This patch adds
>> the fragmentation in the block layer, after requests have been
>> aligned (fragmenting before alignment would lead to multiple
>> unaligned requests, rather than just the head and tail).
>>
>> The return value was previously nebulous on success (sometimes
>> zero, sometimes the length read); since we never have a short
>> read, and since fragmenting may store yet another positive
>> value in 'ret', change the function to always return the
>> incoming 'bytes' value on success.
>>
>> Signed-off-by: Eric Blake <address@hidden>
>>
>> ---
>> v2: Fix uninitialized use of 'ret' for an all-zero read beyond eof
> 
> Uggh. Something I did here and not in v1 is now causing 'make
> check-qtest' failures. Please don't merge until I've posted v3.

Looks like there is at least one caller that expects
bdrv_aligned_preadv() to return 0 (not positive) on success; I'm not
sure which one(s), as it turned into a lot of code to chase, but a
simple tweak to guarantee ret = 0 on success solves the failures in
'make check'.  v3 coming up soon.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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