All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Fam Zheng <famz@redhat.com>
Cc: qemu-devel@nongnu.org, eblake@redhat.com,
	Max Reitz <mreitz@redhat.com>,
	qemu-block@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v15 19/21] osdep: Add qemu_lock_fd and qemu_unlock_fd
Date: Wed, 26 Apr 2017 16:24:56 +0200	[thread overview]
Message-ID: <20170426142456.GJ4538@noname.str.redhat.com> (raw)
In-Reply-To: <20170426132028.GC9205@lemon.lan>

Am 26.04.2017 um 15:20 hat Fam Zheng geschrieben:
> On Wed, 04/26 14:57, Kevin Wolf wrote:
> > Am 26.04.2017 um 05:34 hat Fam Zheng geschrieben:
> > > They are wrappers of POSIX fcntl "file private locking", with a
> > > convenient "try lock" wrapper implemented with F_OFD_GETLK.
> > > 
> > > Signed-off-by: Fam Zheng <famz@redhat.com>
> > > Reviewed-by: Max Reitz <mreitz@redhat.com>
> > > ---
> > >  include/qemu/osdep.h |  3 +++
> > >  util/osdep.c         | 48 ++++++++++++++++++++++++++++++++++++++++++++++++
> > >  2 files changed, 51 insertions(+)
> > > 
> > > diff --git a/include/qemu/osdep.h b/include/qemu/osdep.h
> > > index 122ff06..1c9f5e2 100644
> > > --- a/include/qemu/osdep.h
> > > +++ b/include/qemu/osdep.h
> > > @@ -341,6 +341,9 @@ int qemu_close(int fd);
> > >  #ifndef _WIN32
> > >  int qemu_dup(int fd);
> > >  #endif
> > > +int qemu_lock_fd(int fd, int64_t start, int64_t len, bool exclusive);
> > > +int qemu_unlock_fd(int fd, int64_t start, int64_t len);
> > > +int qemu_lock_fd_test(int fd, int64_t start, int64_t len, bool exclusive);
> > 
> > For the record: On IRC, I proposed adding something like the following:
> > 
> >     #ifndef F_OFD_SETLK
> >     #define F_OFD_SETLK F_SETLK
> >     #define F_OFD_GETLK F_GETLK
> >     #endif
> > 
> > F_OFD_* are still relatively new and e.g. RHEL 7 doesn't support it yet.
> > Using process-based locks is suboptimal because we can easily lose them
> > earlier than we want, but it's still better than nothing and covers the
> > common simple cases.
> 
> Yes, we should add that. But I'd prefer:
> 
>     #ifdef F_OFD_SETLK
>     #define QEMU_SETLK F_OFD_SETLK
>     #define QEMU_GETLK F_OFD_GETLK
>     #else
>     #define QEMU_SETLK F_SETLK
>     #define QEMU_GETLK F_GETLK
>     #endif
> 
> to avoid "abusing" the macro name.

Makes sense.

> Another question is whether we should print a warning to make users
> aware? Even the test case in patch 21 can see three "lock losses" on
> RHEL with posix lock, and there are way more corner cases, I believe.
> 
> We can print a warning to stderr in raw_open_common when F_OFD_GETLK
> is not available, I think.

Yes, this sounds reasonable, too. Dependent on s->use_locks, I guess.

Kevin

  reply	other threads:[~2017-04-26 14:25 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-26  3:33 [Qemu-devel] [PATCH v15 00/21] block: Image locking series Fam Zheng
2017-04-26  3:33 ` [Qemu-devel] [PATCH v15 01/21] block: Make bdrv_perm_names public Fam Zheng
2017-04-26  3:33 ` [Qemu-devel] [PATCH v15 02/21] block: Define BLK_PERM_MAX Fam Zheng
2017-04-26  9:36   ` Kevin Wolf
2017-04-27  2:03     ` Fam Zheng
2017-04-26  3:33 ` [Qemu-devel] [PATCH v15 03/21] block: Add, parse and store "force-share" option Fam Zheng
2017-04-26  3:33 ` [Qemu-devel] [PATCH v15 04/21] block: Respect "force-share" in perm propagating Fam Zheng
2017-04-26  3:33 ` [Qemu-devel] [PATCH v15 05/21] qemu-img: Add --force-share option to subcommands Fam Zheng
2017-04-26  3:33 ` [Qemu-devel] [PATCH v15 06/21] qemu-img: Update documentation for -U Fam Zheng
2017-04-26  3:33 ` [Qemu-devel] [PATCH v15 07/21] qemu-io: Add --force-share option Fam Zheng
2017-04-26  3:34 ` [Qemu-devel] [PATCH v15 08/21] iotests: 030: Prepare for image locking Fam Zheng
2017-04-26  3:34 ` [Qemu-devel] [PATCH v15 09/21] iotests: 046: " Fam Zheng
2017-04-26  3:34 ` [Qemu-devel] [PATCH v15 10/21] iotests: 055: Don't attach the target image already for drive-backup Fam Zheng
2017-04-26  3:34 ` [Qemu-devel] [PATCH v15 11/21] iotests: 085: Avoid image locking conflict Fam Zheng
2017-04-26 12:30   ` Kevin Wolf
2017-04-27  7:16     ` Fam Zheng
2017-04-26  3:34 ` [Qemu-devel] [PATCH v15 12/21] iotests: 087: Don't attach test image twice Fam Zheng
2017-04-26  3:34 ` [Qemu-devel] [PATCH v15 13/21] iotests: 091: Quit QEMU before checking image Fam Zheng
2017-04-26 12:34   ` Kevin Wolf
2017-04-27  7:04     ` Fam Zheng
2017-04-26  3:34 ` [Qemu-devel] [PATCH v15 14/21] iotests: 172: Use separate images for multiple devices Fam Zheng
2017-04-26  3:34 ` [Qemu-devel] [PATCH v15 15/21] tests: Use null-co:// instead of /dev/null as the dummy image Fam Zheng
2017-04-26  3:34 ` [Qemu-devel] [PATCH v15 16/21] file-posix: Add 'locking' option Fam Zheng
2017-04-26 12:41   ` Kevin Wolf
2017-04-27  2:29     ` Fam Zheng
2017-04-26  3:34 ` [Qemu-devel] [PATCH v15 17/21] tests: Disable image lock in test-replication Fam Zheng
2017-04-26  3:34 ` [Qemu-devel] [PATCH v15 18/21] block: Reuse bs as backing hd for drive-backup sync=none Fam Zheng
2017-04-26 12:52   ` Kevin Wolf
2017-04-26 13:15     ` Fam Zheng
2017-04-26 14:34       ` Kevin Wolf
2017-04-27  1:50         ` Fam Zheng
2017-04-26  3:34 ` [Qemu-devel] [PATCH v15 19/21] osdep: Add qemu_lock_fd and qemu_unlock_fd Fam Zheng
2017-04-26 12:57   ` Kevin Wolf
2017-04-26 13:20     ` Fam Zheng
2017-04-26 14:24       ` Kevin Wolf [this message]
2017-04-26 14:29       ` Daniel P. Berrange
2017-04-27  1:40         ` Fam Zheng
2017-04-26  3:34 ` [Qemu-devel] [PATCH v15 20/21] file-posix: Add image locking to perm operations Fam Zheng
2017-04-26 14:22   ` Kevin Wolf
2017-04-27  6:43     ` Fam Zheng
2017-04-28 13:45   ` Kevin Wolf
2017-04-28 15:30     ` Fam Zheng
2017-04-28 18:27       ` Kevin Wolf
2017-04-26  3:34 ` [Qemu-devel] [PATCH v15 21/21] qemu-iotests: Add test case 153 for image locking Fam Zheng
2017-04-26 12:53   ` Fam Zheng
2017-04-26 14:49   ` Kevin Wolf
2017-04-27  1:32     ` Fam Zheng
2017-04-27  9:05       ` Kevin Wolf
2017-04-27 10:34         ` Fam Zheng

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170426142456.GJ4538@noname.str.redhat.com \
    --to=kwolf@redhat.com \
    --cc=eblake@redhat.com \
    --cc=famz@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.