[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 1/2] file-posix: Use OFD lock only if the filesystem supports
From: |
Kevin Wolf |
Subject: |
Re: [PATCH 1/2] file-posix: Use OFD lock only if the filesystem supports the lock |
Date: |
Thu, 19 Nov 2020 11:44:42 +0100 |
Am 18.11.2020 um 20:48 hat Masayoshi Mizuma geschrieben:
> On Wed, Nov 18, 2020 at 02:10:36PM -0500, Masayoshi Mizuma wrote:
> > On Wed, Nov 18, 2020 at 04:42:47PM +0100, Kevin Wolf wrote:
> > > Am 06.11.2020 um 05:01 hat Masayoshi Mizuma geschrieben:
> > > > From: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
> > > >
> > > > locking=auto doesn't work if the filesystem doesn't support OFD lock.
> > > > In that situation, following error happens:
> > > >
> > > > qemu-system-x86_64: -blockdev
> > > > driver=qcow2,node-name=disk,file.driver=file,file.filename=/mnt/guest.qcow2,file.locking=auto:
> > > > Failed to lock byte 100
> > > >
> > > > qemu_probe_lock_ops() judges whether qemu can use OFD lock
> > > > or not with doing fcntl(F_OFD_GETLK) to /dev/null. So the
> > > > error happens if /dev/null supports OFD lock, but the filesystem
> > > > doesn't support the lock.
> > > >
> > > > Lock the actual file, not /dev/null, using F_OFD_SETLK and if that
> > > > fails, then fallback to F_SETLK.
> > > >
> > > > Signed-off-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
> > > > -bool qemu_has_ofd_lock(void)
> > > > -{
> > > > - qemu_probe_lock_ops();
> > > > #ifdef F_OFD_SETLK
> > > > - return fcntl_op_setlk == F_OFD_SETLK;
> > > > +static int _qemu_lock_fcntl(int fd, struct flock *fl)
> > > > +{
> > > > + int ret;
> > > > + bool ofd_lock = true;
> > > > +
> > > > + do {
> > > > + if (ofd_lock) {
> > > > + ret = fcntl(fd, F_OFD_SETLK, fl);
> > > > + if ((ret == -1) && (errno == EINVAL)) {
> > > > + ofd_lock = false;
> > > > + }
> > > > + }
> > > > +
> > > > + if (!ofd_lock) {
> > > > + /* Fallback to POSIX lock */
> > > > + ret = fcntl(fd, F_SETLK, fl);
> > > > + }
> > > > + } while (ret == -1 && errno == EINTR);
> > > > +
> > > > + return ret == -1 ? -errno : 0;
> > > > +}
> > > > #else
> > > > - return false;
> > > > -#endif
> > > > +static int _qemu_lock_fcntl(int fd, struct flock *fl)
> > > > +{
> > > > + int ret;
> > > > +
> > > > + do {
> > > > + ret = fcntl(fd, F_SETLK, fl);
> > > > + } while (ret == -1 && errno == EINTR);
> > > > +
> > > > + return ret == -1 ? -errno : 0;
> > > > }
> > > > +#endif
> > >
> > > The logic looks fine to me, at least assuming that EINVAL is really what
> > > we will consistently get from the kernel if OFD locks are not supported.
> > > Is this documented anywhere? The fcntl manpage doesn't seem to mention
> > > this case.
>
> The man page of fcntl(2) says:
>
> EINVAL The value specified in cmd is not recognized by this kernel.
>
> So I think EINVAL is good enough to check whether the filesystem supports
> OFD locks or not...
A kernel not knowing the cmd at all is a somewhat different case (and
certainly a different code path) than a filesystem not supporting it.
I just had a look at the kernel code, and to me it seems that the
difference between POSIX locks and OFD locks is handled entirely in
filesystem independent code. A filesystem driver would in theory have
ways to distinguish both, but I don't see any driver in the kernel tree
that actually does this (and there is probably little reason for a
driver to do so).
So now I wonder what filesystem you are using? I'm curious what I
missed.
Kevin