Re: [PATCH 1/2] file-posix: Use OFD lock only if the filesystem supports the lock

[Kevin Wolf]

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