qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v4 21/29] util: use fcntl() for qemu_write_pidfi


From: Daniel P . Berrangé
Subject: Re: [Qemu-devel] [PATCH v4 21/29] util: use fcntl() for qemu_write_pidfile() locking
Date: Wed, 29 Aug 2018 09:12:53 +0100
User-agent: Mutt/1.10.1 (2018-07-13)

On Wed, Aug 29, 2018 at 01:41:14AM +0200, Marc-André Lureau wrote:
> Hi
> 
> On Tue, Aug 28, 2018 at 6:01 PM Daniel P. Berrangé <address@hidden> wrote:
> >
> > On Fri, Jul 13, 2018 at 03:09:08PM +0200, Marc-André Lureau wrote:
> > > According to Daniel Berrange, fcntl() locks have better portable
> > > semantics than lockf().
> >
> > Specifically I was referring to this from 'man lockf':
> >
> >    On Linux, lockf() is just an interface  on  top  of  fcntl(2)  locking.
> >    Many other systems implement lockf() in this way, but note that POSIX.1
> >    leaves the relationship between lockf() and fcntl(2) locks unspecified.
> >    A  portable  application  should  probably  avoid mixing calls to these
> >    interfaces.
> >
> > IOW, if its just a shim around fcntl() on many systems, it is clearer
> > if we just use fcntl() directly, as we then know how fcntl() locks will
> > behave if they're on a network filesystem like NFS.
> >
> > > Use an exclusive lock on the first byte with fcntl().
> > >
> > > Signed-off-by: Marc-André Lureau <address@hidden>
> > > ---
> > >  util/oslib-posix.c | 8 +++++++-
> > >  1 file changed, 7 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/util/oslib-posix.c b/util/oslib-posix.c
> > > index da1d4a3201..26b11490b9 100644
> > > --- a/util/oslib-posix.c
> > > +++ b/util/oslib-posix.c
> > > @@ -92,6 +92,11 @@ bool qemu_write_pidfile(const char *pidfile, Error 
> > > **errp)
> > >  {
> > >      int pidfd;
> > >      char pidstr[32];
> > > +    struct flock lock = {
> > > +        .l_type = F_WRLCK,
> > > +        .l_whence = SEEK_SET,
> > > +        .l_len = 1,
> > > +    };
> >
> > For the same semantics as lockf we should use  len == 0 (ie infinity)
> 
> I went to look at how libvirt implements it. Interestingly, it uses
> start=0, len=1, and you added it in:

libvirt never used lockf though. Both are valid, I was just saying that
to be identical to what lockf did, it would use len == 0.


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 :|



reply via email to

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