All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Masayoshi Mizuma <msys.mizuma@gmail.com>
Cc: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>,
	qemu-devel@nongnu.org, qemu-block@nongnu.org
Subject: Re: [PATCH 1/2] file-posix: Use OFD lock only if the filesystem supports the lock
Date: Fri, 20 Nov 2020 16:42:28 +0100	[thread overview]
Message-ID: <20201120154228.GC5599@merkur.fritz.box> (raw)
In-Reply-To: <20201119235650.62vcbycc5fc4oxec@gabell>

Am 20.11.2020 um 00:56 hat Masayoshi Mizuma geschrieben:
> On Thu, Nov 19, 2020 at 11:44:42AM +0100, Kevin Wolf wrote:
> > 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:
> > > > > 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.
> 
> I'm using a proprietary filesystem, which isn't in the linux kernel.
> The filesystem supports posix lock only, doesn't support OFD lock...

Do you know why that proprietary filesystem driver makes a difference
between POSIX locks and OFD locks? The main difference between both
types is when they are released automatically, and this is handled by
generic kernel code and not the filesystem driver.

From a filesystem perspective, I don't see any reason to even
distuingish. So unless there are good reasons for making the
distinction, I'm currently inclined to view this as a filesystem
driver bug.

It makes handling this case hard because when the case isn't even
supposed to exist, of course there won't be a defined error code.

Kevin



  reply	other threads:[~2020-11-20 15:43 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-06  4:01 [PATCH 1/2] file-posix: Use OFD lock only if the filesystem supports the lock Masayoshi Mizuma
2020-11-06  4:01 ` [PATCH 2/2] tests/test-image-locking: Pass the fd to the argument of qemu_has_ofd_lock() Masayoshi Mizuma
2020-11-18 15:44   ` Kevin Wolf
2020-11-18 19:04     ` Masayoshi Mizuma
2020-11-18 15:06 ` [PATCH 1/2] file-posix: Use OFD lock only if the filesystem supports the lock Masayoshi Mizuma
2020-11-18 15:16 ` Daniel P. Berrangé
2020-11-18 19:03   ` Masayoshi Mizuma
2020-11-18 15:42 ` Kevin Wolf
2020-11-18 19:10   ` Masayoshi Mizuma
2020-11-18 19:48     ` Masayoshi Mizuma
2020-11-19 10:44       ` Kevin Wolf
2020-11-19 23:56         ` Masayoshi Mizuma
2020-11-20 15:42           ` Kevin Wolf [this message]
2021-02-10 16:43             ` Masayoshi Mizuma
2021-02-10 17:29               ` Kevin Wolf

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=20201120154228.GC5599@merkur.fritz.box \
    --to=kwolf@redhat.com \
    --cc=m.mizuma@jp.fujitsu.com \
    --cc=msys.mizuma@gmail.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.