qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: pkrempa@redhat.com, Eduardo Habkost <ehabkost@redhat.com>,
	qemu-block@nongnu.org, Markus Armbruster <armbru@redhat.com>,
	qemu-devel@nongnu.org, vsementsov@virtuozzo.com,
	Cleber Rosa <crosa@redhat.com>, Max Reitz <mreitz@redhat.com>,
	John Snow <jsnow@redhat.com>
Subject: Re: [PATCH RFC v2 1/5] block: add bitmap-populate job
Date: Wed, 17 Jun 2020 12:57:46 +0200	[thread overview]
Message-ID: <20200617105746.GB5166@linux.fritz.box> (raw)
In-Reply-To: <aef43939-63eb-8e48-e3ad-dfc12d1f3d21@redhat.com>

Am 16.06.2020 um 22:02 hat Eric Blake geschrieben:
> On 6/16/20 2:46 PM, Eric Blake wrote:
> 
> > > > +BlockJob *bitpop_job_create(
> > 
> > > > +    if (bdrv_op_is_blocked(bs, BLOCK_OP_TYPE_BACKUP_SOURCE, errp)) {
> > > > +        return NULL;
> > > > +    }
> > > 
> > > What does this protect? And why does BACKUP_SOURCE describe acccurately
> > > what this job does?
> > 
> > I'm less certain what the BLOCK_OP_TYPE_* constants are supposed to
> > block, or if this is just copy/paste from backup.c. Does BlockOpType in
> > block.h need a new entry?
> 
> As it is, our code base has slowly moved away from op_blockers.

Yes, this is true. We're now trying to express conflicts with the
permission system instead.

> We no longer have any explicit bdrv_op_block() except when blocking
> everything, then immediately followed up with unblocking a mere subset
> of all of the defined op types:

I believe we never had any other pattern because nobody ever could be
bothered to think about specific conflicts. If we had one example of
conflicting uses, we just blocked everything and only unblocked cases
when we needed them (usually not really knowing whether they were really
always safe). So op blocker are almost always overblocking, but
sometimes too permissive, too.

This is why I was asking what we actually protect against here.

> 
> block.c:    bdrv_op_unblock(backing_hd, BLOCK_OP_TYPE_COMMIT_TARGET,
> block.c:    bdrv_op_unblock(backing_hd, BLOCK_OP_TYPE_STREAM,
> block.c:    bdrv_op_unblock(backing_hd, BLOCK_OP_TYPE_BACKUP_SOURCE,
> block.c:    bdrv_op_unblock(backing_hd, BLOCK_OP_TYPE_BACKUP_TARGET,
> block/replication.c:        bdrv_op_unblock(top_bs, BLOCK_OP_TYPE_DATAPLANE,
> s->blocker);
> blockjob.c:    bdrv_op_unblock(bs, BLOCK_OP_TYPE_DATAPLANE, job->blocker);
> 
> Are we at the point where we can ditch op_blockers altogether in favor of
> the block permissions system?

I actually started some patches to remove op blockers the other day. The
tricky part is proving that each type is really unnecessary now. I only
did this for RESIZE and DATAPLANE, which seemed relatively easy to
prove, though I guess I could send at least these patches.

Kevin



  reply	other threads:[~2020-06-17 10:59 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-14  3:49 [PATCH RFC v2 0/5] block: add block-dirty-bitmap-populate job John Snow
2020-05-14  3:49 ` [PATCH RFC v2 1/5] block: add bitmap-populate job John Snow
2020-05-18 20:49   ` Eric Blake
2020-05-19  8:27     ` Peter Krempa
2020-06-04  9:12     ` Kevin Wolf
2020-06-04  9:16       ` Peter Krempa
2020-06-04 11:31         ` Kevin Wolf
2020-06-04 16:22           ` Peter Krempa
2020-06-05  9:01             ` Kevin Wolf
2020-06-05  9:24               ` Peter Krempa
2020-06-05  9:44                 ` Kevin Wolf
2020-06-05  9:58                   ` Peter Krempa
2020-06-05 10:07                     ` Kevin Wolf
2020-06-05 10:59                       ` Peter Krempa
2020-06-06  6:55                         ` Vladimir Sementsov-Ogievskiy
2020-06-08  9:21                           ` Kevin Wolf
2020-06-08 10:00                             ` Vladimir Sementsov-Ogievskiy
2020-06-08 13:15                               ` Kevin Wolf
2020-06-08  9:38                           ` Peter Krempa
2020-06-08 10:30                             ` Vladimir Sementsov-Ogievskiy
2020-06-08 12:01                               ` Peter Krempa
2020-06-04  9:01   ` Kevin Wolf
2020-06-16 19:46     ` Eric Blake
2020-06-16 19:51       ` John Snow
2020-06-16 20:02       ` Eric Blake
2020-06-17 10:57         ` Kevin Wolf [this message]
2020-05-14  3:49 ` [PATCH RFC v2 2/5] blockdev: combine DriveBackupState and BlockdevBackupState John Snow
2020-05-18 20:57   ` Eric Blake
2020-05-14  3:49 ` [PATCH RFC v2 3/5] qmp: expose block-dirty-bitmap-populate John Snow
2020-05-18 21:10   ` Eric Blake
2020-05-14  3:49 ` [PATCH RFC v2 4/5] iotests: move bitmap helpers into their own file John Snow
2020-05-14  3:49 ` [PATCH RFC v2 5/5] iotests: add 287 for block-dirty-bitmap-populate John Snow
2020-05-18 21:22   ` Eric Blake
2020-06-04  9:24   ` Kevin Wolf
2020-05-18 14:52 ` [PATCH RFC v2 0/5] block: add block-dirty-bitmap-populate job Peter Krempa
2020-06-09 15:04   ` Peter Krempa
2020-06-05 21:51 ` 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=20200617105746.GB5166@linux.fritz.box \
    --to=kwolf@redhat.com \
    --cc=armbru@redhat.com \
    --cc=crosa@redhat.com \
    --cc=eblake@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=jsnow@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=pkrempa@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@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).