All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: qemu-block@nongnu.org, mreitz@redhat.com, pkrempa@redhat.com,
	qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v2 3/8] block: Require auto-read-only for existing fallbacks
Date: Tue, 16 Oct 2018 16:12:43 +0200	[thread overview]
Message-ID: <20181016141243.GH5620@dhcp-200-186.str.redhat.com> (raw)
In-Reply-To: <e61301c2-5865-fb02-c45b-56b4a3622dc3@redhat.com>

Am 12.10.2018 um 19:02 hat Eric Blake geschrieben:
> On 10/12/18 6:55 AM, Kevin Wolf wrote:
> > Some block drivers have traditionally changed their node to read-only
> > mode without asking the user. This behaviour has been marked deprecated
> > since 2.11, expecting users to provide an explicit read-only=on option.
> > 
> > Now that we have auto-read-only=on, enable these drivers to make use of
> > the option.
> > 
> > This is the only use of bdrv_set_read_only(), so we can make it a bit
> > more specific and turn it into a bdrv_apply_auto_read_only() that is
> > more convenient for drivers to use.
> > 
> > Signed-off-by: Kevin Wolf <kwolf@redhat.com>
> > ---
> 
> > +++ b/block.c
> > @@ -266,27 +266,36 @@ int bdrv_can_set_read_only(BlockDriverState *bs, bool read_only,
> >       return 0;
> >   }
> > -/* TODO Remove (deprecated since 2.11)
> > - * Block drivers are not supposed to automatically change bs->read_only.
> > - * Instead, they should just check whether they can provide what the user
> > - * explicitly requested and error out if read-write is requested, but they can
> > - * only provide read-only access. */
> > -int bdrv_set_read_only(BlockDriverState *bs, bool read_only, Error **errp)
> > +/*
> > + * Called by a driver that can only provide a read-only image.
> > + *
> > + * Returns 0 if the node is already read-only or it could switch the node to
> > + * read-only because BDRV_O_AUTO_RDONLY is set.
> > + *
> > + * Returns -EACCES if the node is read-write and BDRV_O_AUTO_RDONLY is not set.
> > + * If @errmsg is not NULL, it is used as the error message for the Error
> > + * object.
> 
> I like it.
> 
> Worth documenting the -EINVAL (copy-on-read prevents setting read-only)
> failure as well?  (The -EPERM failure of bdrv_can_set_read_only() is not
> reachable, since this new function never clears readonly).

In fact, -EINVAL and the error string from bdrv_can_set_read_only() may
be confusing because the user didn't explicitly request a read-only
image. Maybe it would be better to just turn this case into -EACCES with
the same error message.

What do you think?

> > + */
> > +int bdrv_apply_auto_read_only(BlockDriverState *bs, const char *errmsg,
> > +                              Error **errp)
> >   {
> >       int ret = 0;
> > -    ret = bdrv_can_set_read_only(bs, read_only, false, errp);
> > +    if (!(bs->open_flags & BDRV_O_RDWR)) {
> > +        return 0;
> > +    }
> > +    if (!(bs->open_flags & BDRV_O_AUTO_RDONLY)) {
> > +        error_setg(errp, "%s", errmsg ?: "Image is read-only");
> > +        return -EACCES;
> > +    }
> > +
> > +    ret = bdrv_can_set_read_only(bs, true, false, errp);
> >       if (ret < 0) {
> >           return ret;
> >       }
> 
> Makes sense.
> 
> > +++ b/block/vvfat.c
> > @@ -1262,16 +1262,10 @@ static int vvfat_open(BlockDriverState *bs, QDict *options, int flags,
> >                          "Unable to set VVFAT to 'rw' when drive is read-only");
> >               goto fail;
> >           }
> > -    } else  if (!bdrv_is_read_only(bs)) {
> > -        error_report("Opening non-rw vvfat images without an explicit "
> > -                     "read-only=on option is deprecated. Future versions "
> > -                     "will refuse to open the image instead of "
> > -                     "automatically marking the image read-only.");
> > -        /* read only is the default for safety */
> > -        ret = bdrv_set_read_only(bs, true, &local_err);
> > +    } else {
> > +        ret = bdrv_apply_auto_read_only(bs, NULL, errp);
> >           if (ret < 0) {
> > -            error_propagate(errp, local_err);
> > -            goto fail;
> > +            return ret;
> 
> Don't you still need the goto fail, to avoid leaking opts?

Yes, I do. Thanks.

Kevin

  reply	other threads:[~2018-10-16 14:13 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-12 11:55 [Qemu-devel] [PATCH v2 0/8] block: Add auto-read-only option Kevin Wolf
2018-10-12 11:55 ` [Qemu-devel] [PATCH v2 1/8] block: Update flags in bdrv_set_read_only() Kevin Wolf
2018-10-12 16:19   ` Eric Blake
2018-10-17  9:02   ` [Qemu-devel] [Qemu-block] " Alberto Garcia
2018-10-12 11:55 ` [Qemu-devel] [PATCH v2 2/8] block: Add auto-read-only option Kevin Wolf
2018-10-12 16:47   ` Eric Blake
2018-10-15  9:37     ` Kevin Wolf
2018-10-16 18:46       ` Eric Blake
2018-10-12 11:55 ` [Qemu-devel] [PATCH v2 3/8] block: Require auto-read-only for existing fallbacks Kevin Wolf
2018-10-12 17:02   ` Eric Blake
2018-10-16 14:12     ` Kevin Wolf [this message]
2018-10-16 18:51       ` Eric Blake
2018-10-12 11:55 ` [Qemu-devel] [PATCH v2 4/8] nbd: Support auto-read-only option Kevin Wolf
2018-10-12 14:09   ` Eric Blake
2018-10-12 11:55 ` [Qemu-devel] [PATCH v2 5/8] file-posix: " Kevin Wolf
2018-10-12 17:24   ` Eric Blake
2018-10-12 11:55 ` [Qemu-devel] [PATCH v2 6/8] curl: " Kevin Wolf
2018-10-12 17:30   ` Eric Blake
2018-10-12 11:55 ` [Qemu-devel] [PATCH v2 7/8] gluster: " Kevin Wolf
2018-10-12 17:31   ` Eric Blake
2018-10-14 11:04     ` [Qemu-devel] [Qemu-block] " Niels de Vos
2018-10-12 11:55 ` [Qemu-devel] [PATCH v2 8/8] iscsi: " Kevin Wolf
2018-10-12 17:32   ` Eric Blake

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=20181016141243.GH5620@dhcp-200-186.str.redhat.com \
    --to=kwolf@redhat.com \
    --cc=eblake@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=pkrempa@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.