qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>, qemu-block@nongnu.org
Cc: qemu-devel@nongnu.org, mreitz@redhat.com
Subject: Re: [Qemu-devel] [PATCH for-4.1] block/copy-on-read: Fix permissions for inactive node
Date: Mon, 29 Jul 2019 08:35:38 -0500	[thread overview]
Message-ID: <816934c1-419d-10c0-4b13-c6304e832cbb@redhat.com> (raw)
In-Reply-To: <20190729105343.19250-1-kwolf@redhat.com>


[-- Attachment #1.1: Type: text/plain, Size: 2875 bytes --]

On 7/29/19 5:53 AM, Kevin Wolf wrote:
> The copy-on-read drive must not request the WRITE_UNCHANGED permission
> for its child if the node is inactive, otherwise starting a migration
> destination with -incoming will fail because the child cannot provide
> write access yet:
> 
>   qemu-system-x86_64: -blockdev copy-on-read,file=img,node-name=cor: Block node is read-only
> 
> Earlier QEMU versions additionally ran into an abort() on the migration
> source side: bdrv_inactivate_recurse() failed to update permissions.
> This is silently ignored today because it was only supposed to loosen
> restrictions. This is the symptom that was originally reported here:
> 
>   https://bugzilla.redhat.com/show_bug.cgi?id=1733022
> 
> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
> ---
>  block/copy-on-read.c | 16 +++++++---------
>  1 file changed, 7 insertions(+), 9 deletions(-)

Do any of the iotests cover this?  Should they, especially if you are
trying to get this in for -rc3 tomorrow?

> 
> diff --git a/block/copy-on-read.c b/block/copy-on-read.c
> index 22f24fd0db..6631f30205 100644
> --- a/block/copy-on-read.c
> +++ b/block/copy-on-read.c
> @@ -56,16 +56,14 @@ static void cor_child_perm(BlockDriverState *bs, BdrvChild *c,
>                             uint64_t perm, uint64_t shared,
>                             uint64_t *nperm, uint64_t *nshared)
>  {
> -    if (c == NULL) {
> -        *nperm = (perm & PERM_PASSTHROUGH) | BLK_PERM_WRITE_UNCHANGED;
> -        *nshared = (shared & PERM_PASSTHROUGH) | PERM_UNCHANGED;
> -        return;
> -    }
> +    *nperm = perm & PERM_PASSTHROUGH;
> +    *nshared = (shared & PERM_PASSTHROUGH) | PERM_UNCHANGED;
>  
> -    *nperm = (perm & PERM_PASSTHROUGH) |
> -             (c->perm & PERM_UNCHANGED);
> -    *nshared = (shared & PERM_PASSTHROUGH) |
> -               (c->shared_perm & PERM_UNCHANGED);

The old code unconditionally returned one set of permissions when c ==
NULL, or made a choice based on c's existing permissions on whether to
pass in those two bits.

> +    /* We must not request write permissions for an inactive node, the child
> +     * cannot provide it. */
> +    if (!(bs->open_flags & BDRV_O_INACTIVE)) {
> +        *nperm |= BLK_PERM_WRITE_UNCHANGED;
> +    }

The new code changes the condition for or'ing in WRITE_UNCHANGED to
*nperm (it is no longer dependent on whether c == NULL, but whether the
drive is inactive), which matches your commit message.

But the new code also changes to always pass in the PERM_UNCHANGED to
*nshared; that used to be skipped if c was non-NULL and did not already
have the permission.  I don't follow that change from the commit
message, am I missing something?

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2019-07-29 13:36 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-29 10:53 [Qemu-devel] [PATCH for-4.1] block/copy-on-read: Fix permissions for inactive node Kevin Wolf
2019-07-29 13:35 ` Eric Blake [this message]
2019-07-29 14:37   ` Kevin Wolf
2019-07-29 15:31 ` 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=816934c1-419d-10c0-4b13-c6304e832cbb@redhat.com \
    --to=eblake@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --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 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).