[Qemu-devel] image locking

[Qemu-devel] image locking

[Vladimir Sementsov-Ogievskiy]

Hi Fam!

I have a question about your image locking series:

Can you please explain, why OFD locking is enabled by default and posix 
locking is not? What is wrong with posix locking, what are the problems?

-- 
Best regards,
Vladimir

Re: [Qemu-devel] image locking

[Daniel P. Berrange]

On Tue, Sep 19, 2017 at 06:46:19PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> Hi Fam!
> 
> I have a question about your image locking series:
> 
> Can you please explain, why OFD locking is enabled by default and posix
> locking is not? What is wrong with posix locking, what are the problems?

POSIX locking suffers from a horribly broken design making it practically
impossible to use it reliably, particularly in a threaded program. If
there are two file descriptors open to the same file, closing one FD
will release locks held by the other FD. See more details here:

  http://0pointer.de/blog/projects/locking.html

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: [Qemu-devel] [Qemu-block] image locking

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 2413 bytes --]

On 09/19/2017 10:46 AM, Vladimir Sementsov-Ogievskiy wrote:
> Hi Fam!
> 
> I have a question about your image locking series:
> 
> Can you please explain, why OFD locking is enabled by default and posix
> locking is not? What is wrong with posix locking, what are the problems?

POSIX locking (lockf(3), which wraps fcntl(2)) has a severe flaw,
mandated by POSIX due to historical behavior, regarding the duration of
the lock - within a single process, ALL lock access to the same inode,
regardless of which fd triggered the access, is tied together:

int fd1 = open("/dev/null", O_RDONLY);
int fd2 = open("/dev/null", O_RDONLY);
fcntl(F_SETLK, fd1, ...); // Obtain lock
close(fd2); // oops, lock on fd1 is lost!

BSD locks (flock(2)) do not have this issue, but have a different flaw -
they can only lock the entire file at once.  But we need fine-grained
access (we lock different byte ranges in order to convey multiple pieces
of information across processes).

Hence, Linux invented OFD locking as the best of both worlds (the locks
are tied to the inode rather than the process, but allow fine-grained
access), and it is likely that POSIX will eventually standardize it
(http://austingroupbugs.net/view.php?id=768).

More from the Linux 'man fcntl' page:

>        The  record  locks  described  above  are  associated  with the process
>        (unlike the open file description locks  described  below).   This  has
>        some unfortunate consequences:
> 
>        *  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.  This is
>           bad: it means that a process can lose its locks on a  file  such  as
>           /etc/passwd  or  /etc/mtab  when  for some reason a library function
>           decides to open, read, and close the same file.
> 
>        *  The threads in a process share locks.   In  other  words,  a  multi‐
>           threaded  program  can't  use  record locking to ensure that threads
>           don't simultaneously access the same region of a file.
> 
>        Open file description locks solve both of these problems.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 619 bytes --]