All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Fam Zheng <famz@redhat.com>,
	qemu-devel@nongnu.org, qemu-block@nongnu.org
Subject: Re: [Qemu-devel] [Qemu-block] [PATCH 2/2] scsi: add block job opblockers for scsi-block
Date: Thu, 5 Apr 2018 14:43:17 +0200	[thread overview]
Message-ID: <20180405124317.GC4077@localhost.localdomain> (raw)
In-Reply-To: <9aed83cb-e718-3d47-87e1-f66a1c5c7c1a@redhat.com>

Am 05.04.2018 um 13:59 hat Paolo Bonzini geschrieben:
> On 12/03/2018 12:58, Kevin Wolf wrote:
> >> - users of dirty bitmaps would call use perm/shared_perm as in your
> >> message above
> >>
> >> - dirty bitmaps creation calls bdrv_get_cumulative_perm (which should
> >> now become public) and checks that it doesn't have BLK_PERM_BYPASS in
> >> shared_perm
> > 
> > My proposal was really that users of dirty bitmaps don't change
> > anything, but we do everything in the dirty bitmap implementation. Dirty
> > bitmap creation would add a BdrvChild with the above permissions.
> > Deleting a dirty bitmap would remove the BdrvChild again.
> 
> This is also better because it works if somebody requests
> BLK_PERM_BYPASS after dirty bitmap creation.
> 
> However, is there any better way than also creating a dummy BlockDriver
> and BlockDriverState?  I first thought of a root role similar to
> BlockBackend's, but BdrvChildRole doesn't have a way to inject its own
> permissions.  I then tried moving bdrv_child_perm to BdrvChildRole, and
> that almost works except that child_backing has special requirements
> (mostly due to commit_top and mirror_top's special block drivers).

Have a look at block_job_add_bdrv(), which does the same thing to
restrict permissions while a block job is working on the subchain.

Essentially, yes, you'll probably have a new BdrvChildRole (I suppose
with .stay_at_node = true and .get_parent_desc only), but the place
where you specify the permissions is the bdrv_root_attach_child() call.
When you're done, you call bdrv_root_unref_child().

Kevin

> Perhaps child_perm should be in BdrvChildRole and BlockDriverState
> should only have a bdrv_get_backing_perm (called by
> child_backing.child_perm).  This makes sense to me since those
> permissions are specific to the driver, e.g. whether it has metadata at
> all.  But this becomes 2.13 material.
> 
> Do you still object to the two opblocker patches?
> 
> Paolo

      reply	other threads:[~2018-04-05 12:43 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-07 16:36 [Qemu-devel] [PATCH 0/2] scsi: add block job opblockers for scsi-block Paolo Bonzini
2018-02-07 16:36 ` [Qemu-devel] [PATCH 1/2] scsi: add unrealize method for SCSI devices Paolo Bonzini
2018-02-08  1:35   ` Fam Zheng
2018-02-07 16:36 ` [Qemu-devel] [PATCH 2/2] scsi: add block job opblockers for scsi-block Paolo Bonzini
2018-02-08  1:35   ` Fam Zheng
2018-02-08 10:42     ` Paolo Bonzini
2018-02-12 13:52       ` Kevin Wolf
2018-02-12 14:00         ` Paolo Bonzini
2018-02-12 14:30           ` Kevin Wolf
2018-02-12 14:32             ` Paolo Bonzini
2018-02-12 14:48               ` Kevin Wolf
2018-02-12 14:50                 ` Paolo Bonzini
2018-03-12 11:10                   ` [Qemu-devel] [Qemu-block] " Paolo Bonzini
2018-03-12 11:58                     ` Kevin Wolf
2018-04-05 11:59                       ` Paolo Bonzini
2018-04-05 12:43                         ` Kevin Wolf [this message]

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=20180405124317.GC4077@localhost.localdomain \
    --to=kwolf@redhat.com \
    --cc=famz@redhat.com \
    --cc=pbonzini@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.