qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v8 03/36] block: Introduce image file locking


From: Max Reitz
Subject: Re: [Qemu-devel] [PATCH v8 03/36] block: Introduce image file locking
Date: Fri, 21 Oct 2016 23:04:13 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0

On 30.09.2016 14:09, Fam Zheng wrote:
> Block drivers can implement this new operation .bdrv_lockf to actually lock 
> the
> image in the protocol specific way.
> 
> Signed-off-by: Fam Zheng <address@hidden>
> ---
>  block.c                   | 52 
> +++++++++++++++++++++++++++++++++++++++++++++++
>  include/block/block.h     |  4 +++-
>  include/block/block_int.h |  5 +++++
>  include/hw/block/block.h  |  2 ++
>  4 files changed, 62 insertions(+), 1 deletion(-)
> 
> diff --git a/block.c b/block.c
> index 493ecf3..9d600df 100644
> --- a/block.c
> +++ b/block.c
> @@ -235,6 +235,7 @@ BlockDriverState *bdrv_new(void)
>      notifier_with_return_list_init(&bs->before_write_notifiers);
>      bs->refcnt = 1;
>      bs->aio_context = qemu_get_aio_context();
> +    bs->cur_lock = IMAGE_LOCK_MODE__MAX;

(Yes, I know, I'm supposed to write a high-level review, but...)

I don't really like using values for enums that are not actually
supposed to be part of the enum. Maybe nolock would be a reasonable choice?

>      qemu_co_queue_init(&bs->flush_queue);
>  
> @@ -925,6 +926,48 @@ out:
>      g_free(gen_node_name);
>  }
>  
> +ImageLockMode bdrv_lock_mode_from_flags(int flags)
> +{
> +    if (flags & BDRV_O_NO_LOCK) {
> +        return IMAGE_LOCK_MODE_NOLOCK;
> +    } else if (flags & BDRV_O_SHARED_LOCK) {
> +        return IMAGE_LOCK_MODE_SHARED;
> +    } else if (flags & BDRV_O_EXCLUSIVE_LOCK) {
> +        return IMAGE_LOCK_MODE_EXCLUSIVE;
> +    } else {
> +        return IMAGE_LOCK_MODE_AUTO;
> +    }
> +}

I don't know if there's been any discussion about the order of the flags
here, but I personally would order them exactly the other way around:
Asking for exclusive locking should override nolock, in my opinion.

> +
> +ImageLockMode bdrv_get_lock_mode(BlockDriverState *bs)
> +{
> +    return bs->cur_lock;
> +}
> +
> +int bdrv_set_lock_mode(BlockDriverState *bs, ImageLockMode mode)
> +{
> +    int ret;
> +
> +    if (bs->cur_lock == mode) {
> +        return 0;
> +    } else if (!bs->drv) {
> +        return -ENOMEDIUM;
> +    } else if (!bs->drv->bdrv_lockf) {
> +        if (bs->file) {
> +            return bdrv_set_lock_mode(bs->file->bs, mode);
> +        }
> +        return 0;
> +    }
> +    ret = bs->drv->bdrv_lockf(bs, mode);
> +    if (ret == -ENOTSUP) {
> +        /* Handle it the same way as !bs->drv->bdrv_lockf */
> +        ret = 0;

Yes, well, why do you handle both as success? Wouldn't returning
-ENOTSUP make more sense?

I guess the caller can find out itself by checking whether bs->cur_lock
has changed, but...

> +    } else if (ret == 0) {
> +        bs->cur_lock = mode;
> +    }
> +    return ret;
> +}
> +
>  static QemuOptsList bdrv_runtime_opts = {
>      .name = "bdrv_common",
>      .head = QTAILQ_HEAD_INITIALIZER(bdrv_runtime_opts.head),
> @@ -1076,6 +1119,10 @@ static int bdrv_open_common(BlockDriverState *bs, 
> BdrvChild *file,
>          goto free_and_fail;
>      }
>  
> +    if (open_flags & BDRV_O_INACTIVE) {
> +        open_flags = (open_flags & ~BDRV_O_LOCK_MASK) & BDRV_O_NO_LOCK;

I suppose the second & is supposed to be a |?

> +    }
> +
>      ret = refresh_total_sectors(bs, bs->total_sectors);
>      if (ret < 0) {
>          error_setg_errno(errp, -ret, "Could not refresh total sector count");
> @@ -2273,6 +2320,7 @@ static void bdrv_close(BlockDriverState *bs)
>      if (bs->drv) {
>          BdrvChild *child, *next;
>  
> +        bdrv_set_lock_mode(bs, IMAGE_LOCK_MODE_NOLOCK);
>          bs->drv->bdrv_close(bs);
>          bs->drv = NULL;
>  
> @@ -3188,6 +3236,9 @@ void bdrv_invalidate_cache(BlockDriverState *bs, Error 
> **errp)

This function's name is pretty weird... Maybe it would be better to
rename it to "bdrv_complete_incoming" or something. (Unrelated to this
series, of course.)

>          error_setg_errno(errp, -ret, "Could not refresh total sector count");
>          return;
>      }
> +    if (bs->cur_lock != IMAGE_LOCK_MODE__MAX) {
> +        bdrv_set_lock_mode(bs, bs->cur_lock);
> +    }
>  }
>  
>  void bdrv_invalidate_cache_all(Error **errp)
> @@ -3230,6 +3281,7 @@ static int bdrv_inactivate_recurse(BlockDriverState *bs,
>      }
>  
>      if (setting_flag) {
> +        ret = bdrv_set_lock_mode(bs, IMAGE_LOCK_MODE_NOLOCK);

Maybe it would make sense to do something with the return value...? :-)

At least you should probably check whether bdrv_get_lock_mode(bs) ==
IMAGE_LOCK_MODE_NOLOCK.

Max

>          bs->open_flags |= BDRV_O_INACTIVE;
>      }
>      return 0;

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]