On Fri, Nov 20, 2020 at 04:42:28PM +0100, Kevin Wolf wrote: > 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.
Hi Kevin, The filesystem team found a locking issue in the filesystem. Your comments were very helpful! I really appriciate it. Thanks, Masa
