qemu-devel
[Top][All Lists]
Advanced

[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



reply via email to

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