[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 2/3] block: set bs->read_only before .bdrv_open(
From: |
Kevin Wolf |
Subject: |
Re: [Qemu-devel] [PATCH 2/3] block: set bs->read_only before .bdrv_open() |
Date: |
Thu, 27 Oct 2011 12:18:16 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110927 Thunderbird/7.0 |
Am 27.10.2011 11:54, schrieb Stefan Hajnoczi:
> Several block drivers set bs->read_only in .bdrv_open() but
> block.c:bdrv_open_common() clobbers its value. Additionally, QED uses
> bdrv_is_read_only() in .bdrv_open() to decide whether to perform
> consistency checks.
>
> The correct ordering is to initialize bs->read_only from the open flags
> before calling .bdrv_open(). This way block drivers can override it if
> necessary and can use bdrv_is_read_only() in .bdrv_open().
>
> Signed-off-by: Stefan Hajnoczi <address@hidden>
> ---
> block.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/block.c b/block.c
> index 70aab63..3207e99 100644
> --- a/block.c
> +++ b/block.c
> @@ -500,6 +500,8 @@ static int bdrv_open_common(BlockDriverState *bs, const
> char *filename,
> open_flags |= BDRV_O_RDWR;
> }
Not directly related, but the context made me wonder when we're making a
BlockkDriverState writeable unconditionally. This is the full context:
/*
* Snapshots should be writable.
*/
if (bs->is_temporary) {
open_flags |= BDRV_O_RDWR;
}
Does anyone understand what the point of this is? If the user requested
read-only, he certainly wants to have read-only, even if he specified
-snapshot as well.
> + 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);
> @@ -514,8 +516,6 @@ static int bdrv_open_common(BlockDriverState *bs, const
> char *filename,
> goto free_and_fail;
> }
>
> - bs->keep_read_only = bs->read_only = !(open_flags & BDRV_O_RDWR);
> -
The assignment was already at the new place before 4dca4b6. Not sure if
there was any real reason for moving it, though.
Kevin