[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v5 07/27] block: Handle image locking during reo
|
From: |
Fam Zheng |
|
Subject: |
Re: [Qemu-devel] [PATCH v5 07/27] block: Handle image locking during reopen |
|
Date: |
Fri, 27 May 2016 20:36:13 +0800 |
|
User-agent: |
Mutt/1.6.1 (2016-04-27) |
On Fri, 05/27 11:57, Max Reitz wrote:
> On 27.05.2016 09:48, Fam Zheng wrote:
> > On Tue, 05/24 18:28, Max Reitz wrote:
>
> [...]
>
> >> Also: Should bdrv_reopen_prepare() check that the locking flags are not
> >> changed?
> >
> > Read only flag also matters in fcntl locks, so practically we almost always
> > need some change on the lock.
>
> Hm, but as far as I can see, you don't handle changed locking flags
> here; the reopened image is just locked if the old one had been locked
> before. Since the handling of BDRV_O_SHARED_LOCK is done in
> bdrv_lock_unlock_image_do(), that means that BDRV_O_NO_LOCK is ignored
> if changed, isn't it?
Yes you are rigth. I'm reworking this patch and it should fix this problem too.
Fam
- [Qemu-devel] [PATCH v5 03/27] blockdev: Add and parse "lock-mode" option for image locking, (continued)
[Qemu-devel] [PATCH v5 05/27] block: Add bdrv_image_locked, Fam Zheng, 2016/05/17
[Qemu-devel] [PATCH v5 06/27] block: Make bdrv_reopen_{commit, abort} private functions, Fam Zheng, 2016/05/17
[Qemu-devel] [PATCH v5 08/27] osdep: Add qemu_lock_fd and qemu_unlock_fd, Fam Zheng, 2016/05/17
[Qemu-devel] [PATCH v5 12/27] gluster: Implement .bdrv_lockf, Fam Zheng, 2016/05/17
[Qemu-devel] [PATCH v5 09/27] osdep: Introduce qemu_dup, Fam Zheng, 2016/05/17