All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: jcody@redhat.com
Cc: supriyak@linux.vnet.ibm.com, pbonzini@redhat.com,
	eblake@redhat.com, qemu-devel@nongnu.org, stefanha@gmail.com
Subject: Re: [Qemu-devel] [PATCH 1/7] block: correctly set the keep_read_only flag
Date: Wed, 05 Sep 2012 15:12:31 +0200	[thread overview]
Message-ID: <50474FBF.8040607@redhat.com> (raw)
In-Reply-To: <50474EDC.1090204@redhat.com>

Am 05.09.2012 15:08, schrieb Jeff Cody:
> On 09/05/2012 08:47 AM, Kevin Wolf wrote:
>> Am 30.08.2012 20:47, schrieb Jeff Cody:
>>> I believe the bs->keep_read_only flag is supposed to reflect
>>> the initial open state of the device. If the device is initially
>>> opened R/O, then commit operations, or reopen operations changing
>>> to R/W, are prohibited.
>>>
>>> Currently, the keep_read_only flag is only accurate for the active
>>> layer, and its backing file. Subsequent images end up always having
>>> the keep_read_only flag set.
>>>
>>> For instance, what happens now:
>>>
>>> [  base  ]  kro = 1, ro = 1
>>>     |
>>>     v
>>> [ snap-1 ]  kro = 1, ro = 1
>>>     |
>>>     v
>>> [ snap-2 ]  kro = 0, ro = 1
>>>     |
>>>     v
>>> [ active ]  kro = 0, ro = 0
>>>
>>> What we want:
>>>
>>> [  base  ]  kro = 0, ro = 1
>>>     |
>>>     v
>>> [ snap-1 ]  kro = 0, ro = 1
>>>     |
>>>     v
>>> [ snap-2 ]  kro = 0, ro = 1
>>>     |
>>>     v
>>> [ active ]  kro = 0, ro = 0
>>>
>>> Signed-off-by: Jeff Cody <jcody@redhat.com>
>>> ---
>>>  block.c | 16 +++++++---------
>>>  block.h |  1 +
>>>  2 files changed, 8 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/block.c b/block.c
>>> index 470bdcc..e31b76f 100644
>>> --- a/block.c
>>> +++ b/block.c
>>> @@ -655,7 +655,7 @@ static int bdrv_open_common(BlockDriverState *bs, const char *filename,
>>>       * Clear flags that are internal to the block layer before opening the
>>>       * image.
>>>       */
>>> -    open_flags &= ~(BDRV_O_SNAPSHOT | BDRV_O_NO_BACKING);
>>> +    open_flags &= ~(BDRV_O_SNAPSHOT | BDRV_O_NO_BACKING | BDRV_O_ALLOW_RDWR);
>>>  
>>>      /*
>>>       * Snapshots should be writable.
>>> @@ -664,8 +664,6 @@ static int bdrv_open_common(BlockDriverState *bs, const char *filename,
>>>          open_flags |= BDRV_O_RDWR;
>>>      }
>>>  
>>> -    bs->keep_read_only = bs->read_only = !(open_flags & BDRV_O_RDWR);
>>> -
>>>      /* Open the image, either directly or using a protocol */
>>>      if (drv->bdrv_file_open) {
>>>          ret = drv->bdrv_file_open(bs, filename, open_flags);
>>> @@ -804,6 +802,12 @@ int bdrv_open(BlockDriverState *bs, const char *filename, int flags,
>>>          goto unlink_and_fail;
>>>      }
>>>  
>>> +    if (flags & BDRV_O_RDWR) {
>>> +        flags |= BDRV_O_ALLOW_RDWR;
>>> +    }
>>> +
>>> +    bs->keep_read_only = !(flags & BDRV_O_ALLOW_RDWR);
>>
>> Do we still need bs->keep_read_only or is it duplicated in
>> bs->open_flags now? We can convert all users in a follow-up patch.
>>
> 
> I think we can ditch keep_read_only, and just use BDRV_O_ALLOW_RDWR.  The
> only other user of keep_read_only is the original bdrv_commit(), in
> block.c.  And, the natural way to convert that function would be to have
> it use bdrv_reopen(), to change from r/o->r/w.

Ah, yes, makes sense. So just using it in patch 2 and then converting
bdrv_commit() should be enough.

Kevin

  reply	other threads:[~2012-09-05 13:12 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-30 18:47 [Qemu-devel] [PATCH 0/7] block: bdrv_reopen() patches Jeff Cody
2012-08-30 18:47 ` [Qemu-devel] [PATCH 1/7] block: correctly set the keep_read_only flag Jeff Cody
2012-09-05 12:47   ` Kevin Wolf
2012-09-05 13:08     ` Jeff Cody
2012-09-05 13:12       ` Kevin Wolf [this message]
2012-08-30 18:47 ` [Qemu-devel] [PATCH 2/7] block: Framework for reopening files safely Jeff Cody
2012-09-05 15:09   ` Kevin Wolf
2012-09-05 16:38     ` Jeff Cody
2012-09-11 14:57   ` Jeff Cody
2012-09-11 15:14     ` Kevin Wolf
2012-09-11 15:36       ` Jeff Cody
2012-09-11 15:41         ` Kevin Wolf
2012-08-30 18:47 ` [Qemu-devel] [PATCH 3/7] block: raw-posix image file reopen Jeff Cody
2012-08-30 22:15   ` Eric Blake
2012-08-31 14:42     ` Jeff Cody
2012-08-31 14:49       ` Kevin Wolf
2012-08-31 15:10         ` Jeff Cody
2012-09-05 15:30   ` Kevin Wolf
2012-09-05 16:43     ` Jeff Cody
2012-09-06  9:23       ` Kevin Wolf
2012-09-06 15:34         ` Corey Bryant
2012-09-07 10:40           ` Kevin Wolf
2012-09-07 14:29             ` Corey Bryant
2012-08-30 18:47 ` [Qemu-devel] [PATCH 4/7] block: raw " Jeff Cody
2012-08-30 18:47 ` [Qemu-devel] [PATCH 5/7] block: qed " Jeff Cody
2012-08-30 18:47 ` [Qemu-devel] [PATCH 6/7] block: qcow2 " Jeff Cody
2012-08-30 18:47 ` [Qemu-devel] [PATCH 7/7] block: qcow " Jeff Cody

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=50474FBF.8040607@redhat.com \
    --to=kwolf@redhat.com \
    --cc=eblake@redhat.com \
    --cc=jcody@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.com \
    --cc=supriyak@linux.vnet.ibm.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 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.