From: Max Reitz <mreitz@redhat.com>
To: Andrey Shinkevich <andrey.shinkevich@virtuozzo.com>,
qemu-block@nongnu.org
Cc: kwolf@redhat.com, vsementsov@virtuozzo.com, jsnow@redhat.com,
qemu-devel@nongnu.org, armbru@redhat.com, den@openvz.org
Subject: Re: [PATCH v8 5/7] copy-on-read: limit guest writes to base in COR driver
Date: Fri, 4 Sep 2020 14:50:21 +0200 [thread overview]
Message-ID: <667dbbb4-b4b3-1e18-6c9b-466b75cbd00c@redhat.com> (raw)
In-Reply-To: <1598633579-221780-6-git-send-email-andrey.shinkevich@virtuozzo.com>
[-- Attachment #1.1: Type: text/plain, Size: 4012 bytes --]
On 28.08.20 18:52, Andrey Shinkevich wrote:
> Limit the guest's COR operations by the base node in the backing chain
> during a stream job.
I don’t understand. Shouldn’t we limit the areas where we set the COR
flag?
> Signed-off-by: Andrey Shinkevich <andrey.shinkevich@virtuozzo.com>
> ---
> block/copy-on-read.c | 49 +++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 49 insertions(+)
>
> diff --git a/block/copy-on-read.c b/block/copy-on-read.c
> index 1f858bb..ecbd1f8 100644
> --- a/block/copy-on-read.c
> +++ b/block/copy-on-read.c
> @@ -57,6 +57,37 @@ static BlockDriverState *get_base_by_name(BlockDriverState *bs,
> return base_bs;
> }
>
> +/*
> + * Returns 1 if the block is allocated in a node between cor_filter_bs->file->bs
> + * and the base_bs in the backing chain. Otherwise, returns 0.
> + * The COR operation is allowed if the base_bs is not specified - return 1.
> + * Returns negative errno on failure.
> + */
> +static int node_above_base(BlockDriverState *cor_filter_bs, uint64_t offset,
> + uint64_t bytes)
> +{
> + int ret;
> + int64_t dummy;
> + BlockDriverState *file = NULL;
> + BDRVStateCOR *state = cor_filter_bs->opaque;
> +
> + if (!state->base_bs) {
> + return 1;
> + }
> +
> + ret = bdrv_block_status_above(cor_filter_bs->file->bs, state->base_bs,
> + offset, bytes, &dummy, NULL, &file);
> + if (ret < 0) {
> + return ret;
> + }
> +
> + if (file) {
Why check file and not the return value?
> + return 1;
> + }
> +
> + return 0;
“dummy” should really not be called that way, it should be evaluated
whether it’s smaller than bytes.
First, [offset, offset + dummy) may not be allocated above the base –
but [offset + dummy, offset + bytes) may be. Then this function returns
0 here, even though there is something in that range that’s allocated.
Second, in that case we still shouldn’t return 1, but return the
shrunken offset instead. Or, if there are multiple distinct allocated
areas, they should probably even all be copied separately.
(But all of that of course only if this function is intended to be used
to limit where we set the COR flag, because I don’t understand why we’d
want to limit where something can be written.)
Max
> +}
> +
> static int cor_open(BlockDriverState *bs, QDict *options, int flags,
> Error **errp)
> {
> @@ -153,6 +184,12 @@ static int coroutine_fn cor_co_pwritev_part(BlockDriverState *bs,
> QEMUIOVector *qiov,
> size_t qiov_offset, int flags)
> {
> + int ret = node_above_base(bs, offset, bytes);
> +
> + if (!ret || ret < 0) {
> + return ret;
> + }
> +
> return bdrv_co_pwritev_part(bs->file, offset, bytes, qiov, qiov_offset,
> flags);
> }
> @@ -162,6 +199,12 @@ static int coroutine_fn cor_co_pwrite_zeroes(BlockDriverState *bs,
> int64_t offset, int bytes,
> BdrvRequestFlags flags)
> {
> + int ret = node_above_base(bs, offset, bytes);
> +
> + if (!ret || ret < 0) {
> + return ret;
> + }
> +
> return bdrv_co_pwrite_zeroes(bs->file, offset, bytes, flags);
> }
>
> @@ -178,6 +221,12 @@ static int coroutine_fn cor_co_pwritev_compressed(BlockDriverState *bs,
> uint64_t bytes,
> QEMUIOVector *qiov)
> {
> + int ret = node_above_base(bs, offset, bytes);
> +
> + if (!ret || ret < 0) {
> + return ret;
> + }
> +
> return bdrv_co_pwritev(bs->file, offset, bytes, qiov,
> BDRV_REQ_WRITE_COMPRESSED);
> }
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2020-09-04 12:51 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-28 16:52 [PATCH v8 0/7] Apply COR-filter to the block-stream permanently Andrey Shinkevich via
2020-08-28 16:52 ` [PATCH v8 1/7] copy-on-read: Support preadv/pwritev_part functions Andrey Shinkevich via
2020-08-28 16:52 ` [PATCH v8 2/7] copy-on-read: add filter append/drop functions Andrey Shinkevich via
2020-09-04 11:22 ` Max Reitz
2020-09-17 16:09 ` Andrey Shinkevich
2020-09-23 14:38 ` Vladimir Sementsov-Ogievskiy
2020-09-24 13:25 ` Max Reitz
2020-09-24 14:51 ` Vladimir Sementsov-Ogievskiy
2020-09-24 15:00 ` Max Reitz
2020-09-24 17:29 ` Andrey Shinkevich
2020-09-24 17:40 ` Andrey Shinkevich
2020-09-24 17:49 ` Vladimir Sementsov-Ogievskiy
2020-08-28 16:52 ` [PATCH v8 3/7] qapi: add filter-node-name to block-stream Andrey Shinkevich via
2020-08-28 16:52 ` [PATCH v8 4/7] copy-on-read: pass base file name to COR driver Andrey Shinkevich via
2020-09-04 12:17 ` Max Reitz
2020-09-04 12:26 ` Vladimir Sementsov-Ogievskiy
2020-08-28 16:52 ` [PATCH v8 5/7] copy-on-read: limit guest writes to base in " Andrey Shinkevich via
2020-09-04 12:50 ` Max Reitz [this message]
2020-09-04 13:59 ` Vladimir Sementsov-Ogievskiy
2020-09-22 13:13 ` Andrey Shinkevich
2020-09-24 11:18 ` Max Reitz
2020-08-28 16:52 ` [PATCH v8 6/7] block-stream: freeze link to base node during stream job Andrey Shinkevich via
2020-09-04 13:21 ` Max Reitz
2020-09-04 13:48 ` Vladimir Sementsov-Ogievskiy
2020-09-07 11:44 ` Max Reitz
2020-09-07 12:17 ` Vladimir Sementsov-Ogievskiy
2020-09-24 12:46 ` Max Reitz
2020-08-28 16:52 ` [PATCH v8 7/7] block: apply COR-filter to block-stream jobs Andrey Shinkevich via
2020-09-04 13:41 ` Max Reitz
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=667dbbb4-b4b3-1e18-6c9b-466b75cbd00c@redhat.com \
--to=mreitz@redhat.com \
--cc=andrey.shinkevich@virtuozzo.com \
--cc=armbru@redhat.com \
--cc=den@openvz.org \
--cc=jsnow@redhat.com \
--cc=kwolf@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=vsementsov@virtuozzo.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).