All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
To: Stefano Garzarella <sgarzare@redhat.com>
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"qemu-block@nongnu.org" <qemu-block@nongnu.org>,
	"kwolf@redhat.com" <kwolf@redhat.com>,
	"fam@euphon.net" <fam@euphon.net>,
	Denis Lunev <den@virtuozzo.com>,
	"mreitz@redhat.com" <mreitz@redhat.com>,
	"stefanha@redhat.com" <stefanha@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v5 2/3] block/io: bdrv_pdiscard: support int64_t bytes parameter
Date: Tue, 30 Apr 2019 10:03:08 +0000	[thread overview]
Message-ID: <4dabb261-f2d1-b6e0-8d97-ace159b87a54@virtuozzo.com> (raw)
In-Reply-To: <20190430092437.jbecehdkqa4zdavd@steredhat>

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 <vsementsov@virtuozzo.com>
>> ---
>>   include/block/block.h |  4 ++--
>>   block/io.c            | 16 ++++++++--------
>>   2 files changed, 10 insertions(+), 10 deletions(-)
>>
>> diff --git a/include/block/block.h b/include/block/block.h
>> index c7a26199aa..69fa18867e 100644
>> --- a/include/block/block.h
>> +++ b/include/block/block.h
>> @@ -432,8 +432,8 @@ void bdrv_drain_all(void);
>>       AIO_WAIT_WHILE(bdrv_get_aio_context(bs_),              \
>>                      cond); })
>>   
>> -int bdrv_pdiscard(BdrvChild *child, int64_t offset, int bytes);
>> -int bdrv_co_pdiscard(BdrvChild *child, int64_t offset, int bytes);
>> +int bdrv_pdiscard(BdrvChild *child, int64_t offset, int64_t bytes);
>> +int bdrv_co_pdiscard(BdrvChild *child, int64_t offset, int64_t bytes);
>>   int bdrv_has_zero_init_1(BlockDriverState *bs);
>>   int bdrv_has_zero_init(BlockDriverState *bs);
>>   bool bdrv_unallocated_blocks_are_zero(BlockDriverState *bs);
>> diff --git a/block/io.c b/block/io.c
>> index dfc153b8d8..16b6c5d855 100644
>> --- a/block/io.c
>> +++ b/block/io.c
>> @@ -2653,7 +2653,7 @@ int bdrv_flush(BlockDriverState *bs)
>>   typedef struct DiscardCo {
>>       BdrvChild *child;
>>       int64_t offset;
>> -    int bytes;
>> +    int64_t bytes;
>>       int ret;
>>   } DiscardCo;
>>   static void coroutine_fn bdrv_pdiscard_co_entry(void *opaque)
>> @@ -2664,14 +2664,15 @@ static void coroutine_fn bdrv_pdiscard_co_entry(void *opaque)
>>       aio_wait_kick();
>>   }
>>   
>> -int coroutine_fn bdrv_co_pdiscard(BdrvChild *child, int64_t offset, int bytes)
>> +int coroutine_fn bdrv_co_pdiscard(BdrvChild *child, int64_t offset,
>> +                                  int64_t bytes)
>>   {
>>       BdrvTrackedRequest req;
>>       int max_pdiscard, ret;
>>       int head, tail, align;
>>       BlockDriverState *bs = child->bs;
>>   
>> -    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.

> IIUC you added this check because you removed bdrv_check_byte_request()
> below,
> 
> Maybe we can also remove '!bs->drv', since it is checked in
> bdrv_is_inserted().

Hmm, on v4 Kevin commented, that bdrv_is_inserted not needed, and, as I understand, not only
in bdrv_co_pdiscard it should be removed, but it may be done later. So, I'd prefer to keep it
as is for now.

> 
>>           return -ENOMEDIUM;
>>       }
>>   
>> @@ -2679,9 +2680,8 @@ int coroutine_fn bdrv_co_pdiscard(BdrvChild *child, int64_t offset, int bytes)
>>           return -EPERM;
>>       }
>>   
>> -    ret = bdrv_check_byte_request(bs, offset, bytes);
>> -    if (ret < 0) {
>> -        return ret;
>> +    if (offset < 0 || bytes < 0 || bytes > INT64_MAX - offset) {
>> +        return -EIO;
>>       }
> 
> Should we check if 'bytes' is greater than
> 'BDRV_REQUEST_MAX_SECTORS << BDRV_SECTOR_BITS'?
> 

No, as we are contrariwise trying to support large bytes parameter in bdrv_co_pdiscard, which will
exceed max request. If @bytes is large, it will be divided into several smaller requests in the
following loop.


-- 
Best regards,
Vladimir

WARNING: multiple messages have this Message-ID (diff)
From: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
To: Stefano Garzarella <sgarzare@redhat.com>
Cc: "kwolf@redhat.com" <kwolf@redhat.com>,
	"fam@euphon.net" <fam@euphon.net>,
	Denis Lunev <den@virtuozzo.com>,
	"qemu-block@nongnu.org" <qemu-block@nongnu.org>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"mreitz@redhat.com" <mreitz@redhat.com>,
	"stefanha@redhat.com" <stefanha@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v5 2/3] block/io: bdrv_pdiscard: support int64_t bytes parameter
Date: Tue, 30 Apr 2019 10:03:08 +0000	[thread overview]
Message-ID: <4dabb261-f2d1-b6e0-8d97-ace159b87a54@virtuozzo.com> (raw)
Message-ID: <20190430100308.GXlW4SsMYCzLZxjUOHWLwnjQc-WhAzNTI1DfmHvkN-A@z> (raw)
In-Reply-To: <20190430092437.jbecehdkqa4zdavd@steredhat>

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 <vsementsov@virtuozzo.com>
>> ---
>>   include/block/block.h |  4 ++--
>>   block/io.c            | 16 ++++++++--------
>>   2 files changed, 10 insertions(+), 10 deletions(-)
>>
>> diff --git a/include/block/block.h b/include/block/block.h
>> index c7a26199aa..69fa18867e 100644
>> --- a/include/block/block.h
>> +++ b/include/block/block.h
>> @@ -432,8 +432,8 @@ void bdrv_drain_all(void);
>>       AIO_WAIT_WHILE(bdrv_get_aio_context(bs_),              \
>>                      cond); })
>>   
>> -int bdrv_pdiscard(BdrvChild *child, int64_t offset, int bytes);
>> -int bdrv_co_pdiscard(BdrvChild *child, int64_t offset, int bytes);
>> +int bdrv_pdiscard(BdrvChild *child, int64_t offset, int64_t bytes);
>> +int bdrv_co_pdiscard(BdrvChild *child, int64_t offset, int64_t bytes);
>>   int bdrv_has_zero_init_1(BlockDriverState *bs);
>>   int bdrv_has_zero_init(BlockDriverState *bs);
>>   bool bdrv_unallocated_blocks_are_zero(BlockDriverState *bs);
>> diff --git a/block/io.c b/block/io.c
>> index dfc153b8d8..16b6c5d855 100644
>> --- a/block/io.c
>> +++ b/block/io.c
>> @@ -2653,7 +2653,7 @@ int bdrv_flush(BlockDriverState *bs)
>>   typedef struct DiscardCo {
>>       BdrvChild *child;
>>       int64_t offset;
>> -    int bytes;
>> +    int64_t bytes;
>>       int ret;
>>   } DiscardCo;
>>   static void coroutine_fn bdrv_pdiscard_co_entry(void *opaque)
>> @@ -2664,14 +2664,15 @@ static void coroutine_fn bdrv_pdiscard_co_entry(void *opaque)
>>       aio_wait_kick();
>>   }
>>   
>> -int coroutine_fn bdrv_co_pdiscard(BdrvChild *child, int64_t offset, int bytes)
>> +int coroutine_fn bdrv_co_pdiscard(BdrvChild *child, int64_t offset,
>> +                                  int64_t bytes)
>>   {
>>       BdrvTrackedRequest req;
>>       int max_pdiscard, ret;
>>       int head, tail, align;
>>       BlockDriverState *bs = child->bs;
>>   
>> -    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.

> IIUC you added this check because you removed bdrv_check_byte_request()
> below,
> 
> Maybe we can also remove '!bs->drv', since it is checked in
> bdrv_is_inserted().

Hmm, on v4 Kevin commented, that bdrv_is_inserted not needed, and, as I understand, not only
in bdrv_co_pdiscard it should be removed, but it may be done later. So, I'd prefer to keep it
as is for now.

> 
>>           return -ENOMEDIUM;
>>       }
>>   
>> @@ -2679,9 +2680,8 @@ int coroutine_fn bdrv_co_pdiscard(BdrvChild *child, int64_t offset, int bytes)
>>           return -EPERM;
>>       }
>>   
>> -    ret = bdrv_check_byte_request(bs, offset, bytes);
>> -    if (ret < 0) {
>> -        return ret;
>> +    if (offset < 0 || bytes < 0 || bytes > INT64_MAX - offset) {
>> +        return -EIO;
>>       }
> 
> Should we check if 'bytes' is greater than
> 'BDRV_REQUEST_MAX_SECTORS << BDRV_SECTOR_BITS'?
> 

No, as we are contrariwise trying to support large bytes parameter in bdrv_co_pdiscard, which will
exceed max request. If @bytes is large, it will be divided into several smaller requests in the
following loop.


-- 
Best regards,
Vladimir

  reply	other threads:[~2019-04-30 10:18 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-23 12:57 [Qemu-devel] [PATCH v5 0/3] Fix overflow bug in qcow2 discard Vladimir Sementsov-Ogievskiy
2019-04-23 12:57 ` Vladimir Sementsov-Ogievskiy
2019-04-23 12:57 ` [Qemu-devel] [PATCH v5 1/3] block/qcow2-refcount: add trace-point to qcow2_process_discards Vladimir Sementsov-Ogievskiy
2019-04-23 12:57   ` Vladimir Sementsov-Ogievskiy
2019-04-23 12:57 ` [Qemu-devel] [PATCH v5 2/3] block/io: bdrv_pdiscard: support int64_t bytes parameter Vladimir Sementsov-Ogievskiy
2019-04-23 12:57   ` Vladimir Sementsov-Ogievskiy
2019-04-30  9:24   ` Stefano Garzarella
2019-04-30  9:24     ` Stefano Garzarella
2019-04-30 10:03     ` Vladimir Sementsov-Ogievskiy [this message]
2019-04-30 10:03       ` Vladimir Sementsov-Ogievskiy
2019-04-30 11:09       ` Kevin Wolf
2019-04-30 11:09         ` Kevin Wolf
2019-04-30 15:41         ` Eric Blake
2019-05-02  9:11           ` Stefano Garzarella
2019-05-02  9:11             ` Stefano Garzarella
2019-05-06 11:47             ` Vladimir Sementsov-Ogievskiy
2019-04-30 14:25       ` Stefano Garzarella
2019-04-30 14:25         ` Stefano Garzarella
2019-04-23 12:57 ` [Qemu-devel] [PATCH v5 3/3] iotests: test big qcow2 shrink Vladimir Sementsov-Ogievskiy
2019-04-23 12:57   ` Vladimir Sementsov-Ogievskiy
2019-05-21  9:38 ` [Qemu-devel] [PATCH v5 0/3] Fix overflow bug in qcow2 discard Vladimir Sementsov-Ogievskiy
2019-06-03 12:30   ` [Qemu-devel] ping " Vladimir Sementsov-Ogievskiy
2019-06-03 13:40 ` [Qemu-devel] " Kevin Wolf
2019-06-03 13:52   ` Vladimir Sementsov-Ogievskiy

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=4dabb261-f2d1-b6e0-8d97-ace159b87a54@virtuozzo.com \
    --to=vsementsov@virtuozzo.com \
    --cc=den@virtuozzo.com \
    --cc=fam@euphon.net \
    --cc=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=sgarzare@redhat.com \
    --cc=stefanha@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.