From: "Richard W.M. Jones" <rjones@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: qemu-block@nongnu.org, mreitz@redhat.com, eblake@redhat.com,
qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH for-2.9] block: Don't check permissions for copy on read
Date: Fri, 7 Apr 2017 11:42:16 +0100 [thread overview]
Message-ID: <20170407104216.GU30620@redhat.com> (raw)
In-Reply-To: <1491561165-12415-1-git-send-email-kwolf@redhat.com>
On Fri, Apr 07, 2017 at 12:32:45PM +0200, Kevin Wolf wrote:
> The assertion is currently failing. We can't require callers to have
> write permissions when all they are doing is a read, so comment it out.
> Add a FIXME comment in the code so that the check is re-enabled when
> copy on read is refactored into its own filter driver.
>
> Reported-by: Richard W.M. Jones <rjones@redhat.com>
> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Thanks Kevin. As this is essentially the same as the patch I tested
last night,
Reviewed-by: Richard W.M. Jones <rjones@redhat.com>
Rich.
> block/io.c | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/block/io.c b/block/io.c
> index 2709a70..7321dda 100644
> --- a/block/io.c
> +++ b/block/io.c
> @@ -945,7 +945,14 @@ static int coroutine_fn bdrv_co_do_copy_on_readv(BdrvChild *child,
> size_t skip_bytes;
> int ret;
>
> - assert(child->perm & (BLK_PERM_WRITE_UNCHANGED | BLK_PERM_WRITE));
> + /* FIXME We cannot require callers to have write permissions when all they
> + * are doing is a read request. If we did things right, write permissions
> + * would be obtained anyway, but internally by the copy-on-read code. As
> + * long as it is implemented here rather than in a separat filter driver,
> + * the copy-on-read code doesn't have its own BdrvChild, however, for which
> + * it could request permissions. Therefore we have to bypass the permission
> + * system for the moment. */
> + // assert(child->perm & (BLK_PERM_WRITE_UNCHANGED | BLK_PERM_WRITE));
>
> /* Cover entire cluster so no additional backing file I/O is required when
> * allocating cluster in the image file.
> --
> 1.8.3.1
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
next prev parent reply other threads:[~2017-04-07 10:42 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-07 10:32 [Qemu-devel] [PATCH for-2.9] block: Don't check permissions for copy on read Kevin Wolf
2017-04-07 10:42 ` Richard W.M. Jones [this message]
2017-04-07 13:53 ` Eric Blake
2017-04-07 14:01 ` 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=20170407104216.GU30620@redhat.com \
--to=rjones@redhat.com \
--cc=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 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.