qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v5 2/3] block/io: bdrv_pdiscard: support int64_t


From: Vladimir Sementsov-Ogievskiy
Subject: Re: [Qemu-devel] [PATCH v5 2/3] block/io: bdrv_pdiscard: support int64_t bytes parameter
Date: Mon, 6 May 2019 11:47:17 +0000

02.05.2019 12:11, Stefano Garzarella wrote:
> On Tue, Apr 30, 2019 at 10:41:02AM -0500, Eric Blake wrote:
>> On 4/30/19 6:09 AM, Kevin Wolf wrote:
>>> Am 30.04.2019 um 12:03 hat Vladimir Sementsov-Ogievskiy geschrieben:
>>>> 30.04.2019 12:24, Stefano Garzarella wrote:
>>>>> On Tue, Apr 23, 2019 at 03:57:05PM +0300, Vladimir Sementsov-Ogievskiy 
>>>>> wrote:
>>>>>> This fixes at least one overflow in qcow2_process_discards, which
>>>>>> passes 64bit region length to bdrv_pdiscard where bytes (or sectors in
>>>>>> the past) parameter is int since its introduction in 0b919fae.
>>>>>>
>>>>>> Signed-off-by: Vladimir Sementsov-Ogievskiy <address@hidden>
>>
>>>>>> -    if (!bs || !bs->drv) {
>>>>>> +    if (!bs || !bs->drv || !bdrv_is_inserted(bs)) {
>>>>>
>>>>> Should we describe this change in the commit message?
>>>>
>>>> Honestly, don't want to resend the series for this.
>>>
>>> I haven't reviewed the patches yet, but if this remains the only thing
>>> to change, it can be updated while applying the series if we have a
>>> specific proposal for a new commit message.
>>
>> How about:
>>
>> This fixes at least one overflow in qcow2_process_discards, which was
>> inadvertently truncating a 64-bit region length to the bdrv_pdiscard
>> 'int bytes' parameter (previously bdrv_discard's 'int sectors') since
>> its introduction in 0b919fae.
>>
>> By inlining the remaining portions of bdrv_check_byte_request() that are
>> still independent from the code previously validating a 32-bit request,
>> we can drop the call to that function. A request larger than 31 bits (or
>> the driver's max discard limit, if specified) is still split into
>> smaller chunks by the block layer before reaching the driver.
>>
> 
> That sounds good to me!
> 

And for me. Thank you, Eric!


-- 
Best regards,
Vladimir

reply via email to

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