From: Max Reitz <mreitz@redhat.com>
To: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>,
qemu-block@nongnu.org
Cc: kwolf@redhat.com, qemu-devel@nongnu.org, qemu-stable@nongnu.org
Subject: Re: [PATCH v2 2/2] iotests: add test for backup-top failure on permission activation
Date: Tue, 21 Jan 2020 17:31:36 +0100 [thread overview]
Message-ID: <0913d27f-ce33-4f46-1b98-d6744a3336c0@redhat.com> (raw)
In-Reply-To: <20200121142802.21467-3-vsementsov@virtuozzo.com>
[-- Attachment #1.1: Type: text/plain, Size: 3544 bytes --]
On 21.01.20 15:28, Vladimir Sementsov-Ogievskiy wrote:
> This test checks that bug is really fixed by previous commit.
>
> Cc: qemu-stable@nongnu.org # v4.2.0
> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
> ---
> tests/qemu-iotests/283 | 92 ++++++++++++++++++++++++++++++++++++++
> tests/qemu-iotests/283.out | 8 ++++
> tests/qemu-iotests/group | 1 +
> 3 files changed, 101 insertions(+)
> create mode 100644 tests/qemu-iotests/283
> create mode 100644 tests/qemu-iotests/283.out
>
> diff --git a/tests/qemu-iotests/283 b/tests/qemu-iotests/283
> new file mode 100644
> index 0000000000..293e557bd9
> --- /dev/null
> +++ b/tests/qemu-iotests/283
> @@ -0,0 +1,92 @@
[...]
> +""" Test description
> +
> +When performing a backup, all writes on the source subtree must go through the
> +backup-top filter so it can copy all data to the target before it is changed.
> +backup-top filter is appended above source node, to achieve this thing, so all
> +parents of source node are handled. A configuration with side parents of source
> +sub-tree with write permission is unsupported (we'd have append several
> +backup-top filter like nodes to handle such parents). The test create an
> +example of such configuration and checks that a backup is then not allowed
> +(blockdev-backup command should fail).
> +
> +The configuration:
> +
> + ┌────────┐ target ┌─────────────┐
> + │ target │ ◀─────── │ backup_top │
> + └────────┘ └─────────────┘
> + │
> + │ backing
> + ▼
> + ┌─────────────┐
> + │ source │
> + └─────────────┘
> + │
> + │ file
> + ▼
> + ┌─────────────┐ write perm ┌───────┐
> + │ base │ ◀──────────── │ other │
> + └─────────────┘ └───────┘
> +
> +On activation (see .active field of backup-top state in block/backup-top.c),
> +backup-top is going to unshare write permission on its source child. Write
> +unsharing will be propagated to the "source->base" link and will conflict with
> +other node write permission. So permission update will fail and backup job will
> +not be started.
> +
> +Note, that the only thing which prevents backup of running on such
> +configuration is default permission propagation scheme. It may be altered by
> +different block drivers, so backup will run in invalid configuration. But
> +something is better than nothing. Also, before the previous commit (commit
> +preceding this test creation), starting backup on such configuration led to
> +crash, so current "something" is a lot better, and this test actual goal is
> +to check that crash is fixed :)
Thanks a lot for bearing with me!
I was wondering whether this is the first smiley in our code, but it
isn’t. (Not unfortunately, I think. :-)) It’s also not the first
smiley in the iotests, but the second one! (As far as I can tell.)
Max
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2020-01-21 16:32 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-21 14:28 [PATCH v2 0/2] backup-top failure path fix Vladimir Sementsov-Ogievskiy
2020-01-21 14:28 ` [PATCH v2 1/2] block/backup-top: fix failure path Vladimir Sementsov-Ogievskiy
2020-01-21 14:28 ` [PATCH v2 2/2] iotests: add test for backup-top failure on permission activation Vladimir Sementsov-Ogievskiy
2020-01-21 16:31 ` Max Reitz [this message]
2020-01-21 16:32 ` [PATCH v2 0/2] backup-top failure path fix Max Reitz
2020-01-21 16:34 ` 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=0913d27f-ce33-4f46-1b98-d6744a3336c0@redhat.com \
--to=mreitz@redhat.com \
--cc=kwolf@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-stable@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).