[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v3 08/27] osdep: Add qemu_lock_fd and qemu_unloc
From: |
Fam Zheng |
Subject: |
Re: [Qemu-devel] [PATCH v3 08/27] osdep: Add qemu_lock_fd and qemu_unlock_fd |
Date: |
Tue, 10 May 2016 10:43:15 +0800 |
User-agent: |
Mutt/1.6.1 (2016-04-27) |
On Wed, 05/04 14:46, Richard W.M. Jones wrote:
> On Thu, Apr 28, 2016 at 08:57:27PM +0800, Fam Zheng wrote:
> > They are wrappers of POSIX fcntl file locking, with the additional
> > interception of open/close (through qemu_open and qemu_close) to offer a
> > better semantics that preserves the locks across multiple life cycles of
> > different fds on the same file. The reason to make this semantics
> > change over the fcntl locks is to make the API cleaner for QEMU
> > subsystems.
> >
> > More precisely, we remove this "feature" of fcntl lock:
> >
> > If a process closes any file descriptor referring to a file, then
> > all of the process's locks on that file are released, regardless of
> > the file descriptor(s) on which the locks were obtained.
> >
> > as long as the fd is always open/closed through qemu_open and
> > qemu_close.
>
> > + ret = qemu_lock_do(fd, start, len, readonly ? F_RDLCK : F_WRLCK);
> > + if (ret == -1) {
> > + return -errno;
> > + }
>
> It still appears this patch would break libguestfs's valid use case.
>
> How about addressing what Dan wrote here:
>
> https://lists.gnu.org/archive/html/qemu-devel/2016-04/msg02927.html
OK. It means we then don't lock ro images at all. Fair enough and I will
respin.
Fam