On Wed, 30 Nov 2022 at 14:40, Jeff Layton <jlayton@xxxxxxxxxx> wrote:
> This wouldn't obviate FUSE's support for POSIX locks, but I do see a
> problem for FUSE here. It looks like FUSE doesn't record POSIX locks in
> the local inode. Without that, it'd never unlock due to the optimization
> at the start of locks_remove_posix.
Indeed.
> That'd be pretty simple to fix though. We could add a fstype flag that
> just says "don't trust that list_empty check and always unlock". We'd
> set that for FUSE and you'd still get the whole-file unlock call down to
> the fs for any inode with a file_lock_context.
FUSE took that path, because it seemed impossible or impractical to
keep the kernel's locking state in sync with the filesystem's locking
state. It was a long time ago and I don't remember the details.
Unfortunately the commit message doesn't help to explain either...
commit 7142125937e1482ad3ae4366594c6586153dfc86
Author: Miklos Szeredi <miklos@xxxxxxxxxx>
Date: Sun Jun 25 05:48:52 2006 -0700
[PATCH] fuse: add POSIX file locking support
This patch adds POSIX file locking support to the fuse interface.
This implementation doesn't keep any locking state in kernel. Unlocking on
close() is handled by the FLUSH message, which now contains the
lock owner id.
Mandatory locking is not supported. The filesystem may enfoce mandatory
locking in userspace if needed.
Signed-off-by: Miklos Szeredi <miklos@xxxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxx>
Signed-off-by: Linus Torvalds <torvalds@xxxxxxxx>
Thanks,
Miklos
