qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Fam Zheng <famz@redhat.com>
Cc: qemu-block@nongnu.org, mreitz@redhat.com, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 6/6] block: Fix permissions after bdrv_reopen()
Date: Mon, 18 Sep 2017 09:43:44 +0200	[thread overview]
Message-ID: <20170918074344.GC31915@localhost.localdomain> (raw)
In-Reply-To: <20170918073741.GJ15551@lemon.lan>

Am 18.09.2017 um 09:37 hat Fam Zheng geschrieben:
> On Fri, 09/15 12:10, Kevin Wolf wrote:
> > If we switch between read-only and read-write, the permissions that
> > image format drivers need on bs->file change, too. Make sure to update
> > the permissions during bdrv_reopen().
> > 
> > Signed-off-by: Kevin Wolf <kwolf@redhat.com>
> > ---
> >  include/block/block.h |  1 +
> >  block.c               | 64 +++++++++++++++++++++++++++++++++++++++++++++++++++
> >  2 files changed, 65 insertions(+)
> > 
> > diff --git a/include/block/block.h b/include/block/block.h
> > index 082eb2cd9c..3c3af462e4 100644
> > --- a/include/block/block.h
> > +++ b/include/block/block.h
> > @@ -166,6 +166,7 @@ typedef QSIMPLEQ_HEAD(BlockReopenQueue, BlockReopenQueueEntry) BlockReopenQueue;
> >  typedef struct BDRVReopenState {
> >      BlockDriverState *bs;
> >      int flags;
> > +    uint64_t perm, shared_perm;
> >      QDict *options;
> >      QDict *explicit_options;
> >      void *opaque;
> > diff --git a/block.c b/block.c
> > index 204cbb46c7..5c65fac672 100644
> > --- a/block.c
> > +++ b/block.c
> > @@ -2781,6 +2781,10 @@ static BlockReopenQueue *bdrv_reopen_queue_child(BlockReopenQueue *bs_queue,
> >      bs_entry->state.explicit_options = explicit_options;
> >      bs_entry->state.flags = flags;
> >  
> > +    /* This needs to be overwritten in bdrv_reopen_prepare() */
> > +    bs_entry->state.perm = UINT64_MAX;
> 
> Probably doesn't matter because as the comment says it will be overwritten soon,
> but is BLK_PERM_ALL more appropriate?

I had BLK_PERM_ALL at first, but after debugging some assertion failures
in gdb, I came to the conclusion that UINT64_MAX is easier to identify as
uninitialised than BLK_PERM_ALL, which could be a valid result of the
permission calculation.

Kevin

  reply	other threads:[~2017-09-18  7:43 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-15 10:10 [Qemu-devel] [PATCH 0/6] block: Fix permissions after ro/rw reopen Kevin Wolf
2017-09-15 10:10 ` [Qemu-devel] [PATCH 1/6] qemu-io: Reset qemuio_blk permissions before each command Kevin Wolf
2017-09-15 17:44   ` Eric Blake
2017-09-18  7:16   ` Fam Zheng
2017-09-21 13:53   ` Kevin Wolf
2017-09-22 10:46     ` [Qemu-devel] [Qemu-block] " Kevin Wolf
2017-09-22 12:55   ` [Qemu-devel] [PATCH v2 1/6] qemu-io: Drop write permissions before read-only reopen Kevin Wolf
2017-09-22 13:22     ` Fam Zheng
2017-09-15 10:10 ` [Qemu-devel] [PATCH 2/6] block: Add reopen_queue to bdrv_child_perm() Kevin Wolf
2017-09-15 17:51   ` Eric Blake
2017-09-15 10:10 ` [Qemu-devel] [PATCH 3/6] block: Add reopen queue to bdrv_check_perm() Kevin Wolf
2017-09-15 18:39   ` Eric Blake
2017-09-15 10:10 ` [Qemu-devel] [PATCH 4/6] block: Base permissions on rw state after reopen Kevin Wolf
2017-09-15 18:58   ` Eric Blake
2017-09-15 10:10 ` [Qemu-devel] [PATCH 5/6] block: reopen: Queue children after their parents Kevin Wolf
2017-09-15 19:01   ` Eric Blake
2017-09-15 10:10 ` [Qemu-devel] [PATCH 6/6] block: Fix permissions after bdrv_reopen() Kevin Wolf
2017-09-15 19:06   ` Eric Blake
2017-09-18  9:35     ` Kevin Wolf
2017-09-18  7:37   ` Fam Zheng
2017-09-18  7:43     ` Kevin Wolf [this message]
2017-09-15 17:02 ` [Qemu-devel] [PATCH 7/6] qemu-iotests: Test change-backing-file command Kevin Wolf
2017-09-15 19:14   ` Eric Blake
2017-09-18  7:51 ` [Qemu-devel] [PATCH 0/6] block: Fix permissions after ro/rw reopen Fam Zheng
2017-09-18  8:11   ` Kevin Wolf
2017-09-18 11:53     ` Fam Zheng
2017-09-18 12:11       ` Kevin Wolf
2017-09-18 12:32         ` Fam Zheng
2017-09-20 10:33 ` Kevin Wolf

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=20170918074344.GC31915@localhost.localdomain \
    --to=kwolf@redhat.com \
    --cc=famz@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).