From: Peter Lieven <pl@kamp.de>
To: "Denis V. Lunev" <den@openvz.org>, Kevin Wolf <kwolf@redhat.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 1/1] nbd: fix max_discard/max_transfer_length
Date: Fri, 06 Feb 2015 13:01:53 +0100 [thread overview]
Message-ID: <54D4AD31.8070204@kamp.de> (raw)
In-Reply-To: <54D4AC9C.9000005@openvz.org>
Am 06.02.2015 um 12:59 schrieb Denis V. Lunev:
> On 06/02/15 14:53, Kevin Wolf wrote:
>> Am 06.02.2015 um 12:24 hat Denis V. Lunev geschrieben:
>>> nbd_co_discard calls nbd_client_session_co_discard which uses uint32_t
>>> as the length in bytes of the data to discard due to the following
>>> definition:
>>>
>>> struct nbd_request {
>>> uint32_t magic;
>>> uint32_t type;
>>> uint64_t handle;
>>> uint64_t from;
>>> uint32_t len; <-- the length of data to be discarded, in bytes
>>> } QEMU_PACKED;
>>>
>>> Thus we should limit bl_max_discard to UINT32_MAX >> BDRV_SECTOR_BITS to
>>> avoid overflow.
>>>
>>> NBD read/write code uses the same structure for transfers. Fix
>>> max_transfer_length accordingly.
>>>
>>> Signed-off-by: Denis V. Lunev <den@openvz.org>
>>> CC: Peter Lieven <pl@kamp.de>
>>> CC: Kevin Wolf <kwolf@redhat.com>
>> Thanks, I have applied both Peter's and your patch. Can you guys please
>> check whether the current state of my block branch is correct or whether
>> I forgot to include or remove some patch?
> can you give me tree URL?
>
>> By the way, I don't think this NBD patch is strictly necessary as you'll
>> have a hard time finding a platform where INT_MAX > UINT32_MAX, but I
>> think it's good documentation at least and a safeguard if we ever decide
>> to lift the general block layer restrictions.
>>
>> Kevin
> nope, it is absolutely mandatory
>
> stdint.h:
>
> /* Limit of `size_t' type. */
> # if __WORDSIZE == 64
> # define SIZE_MAX (18446744073709551615UL)
> # else
> # define SIZE_MAX (4294967295U)
> # endif
>
> Den
Yes, but we limit to MIN(SIZE_MAX >> BDRV_SECTOR_BITS, INT_MAX >> BDRV_SECTOR_BITS) anyway.
I do not know if there is a platform where INT_MAX is 2^63 - 1 and not 2^31 - 1 ?
We can keep Dens patch in. Just in case. It doesn't hurt.
Peter
next prev parent reply other threads:[~2015-02-06 12:02 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-06 10:54 [Qemu-devel] [PATCH V2] block: introduce BDRV_REQUEST_MAX_SECTORS Peter Lieven
2015-02-06 11:24 ` [Qemu-devel] [PATCH 1/1] nbd: fix max_discard/max_transfer_length Denis V. Lunev
2015-02-06 11:53 ` Kevin Wolf
2015-02-06 11:59 ` Denis V. Lunev
2015-02-06 12:01 ` Peter Lieven [this message]
2015-02-06 12:07 ` Kevin Wolf
2015-02-06 12:17 ` Denis V. Lunev
2015-02-06 12:22 ` Peter Lieven
2015-02-06 12:24 ` Denis V. Lunev
2015-02-06 12:16 ` Peter Lieven
2015-02-06 12:48 ` Kevin Wolf
2015-02-06 11:24 ` [Qemu-devel] [PATCH V2] block: introduce BDRV_REQUEST_MAX_SECTORS Denis V. Lunev
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=54D4AD31.8070204@kamp.de \
--to=pl@kamp.de \
--cc=den@openvz.org \
--cc=kwolf@redhat.com \
--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 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.