Linux Kernel Selftest development
 help / color / mirror / Atom feed
From: Stanislav Kinsburskii <skinsburskii@gmail.com>
To: Randy Dunlap <rdunlap@infradead.org>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
	Jonathan Corbet <corbet@lwn.net>,
	Shuah Khan <skhan@linuxfoundation.org>,
	Shuah Khan <shuah@kernel.org>,
	Robert Byrnes <byrnes@wildpumpkin.net>,
	fuse-devel@lists.linux.dev, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org
Subject: Re: [PATCH v2 1/2] fuse: add negotiated per-inode open and release suppression
Date: Thu, 8 Oct 2026 12:21:50 -0700	[thread overview]
Message-ID: <asftTiSldKhdNEYA@skinsburskii> (raw)
In-Reply-To: <2621089d-f087-4b0d-89bf-3cd1218b5f66@infradead.org>

On Thu, Oct 08, 2026 at 11:17:46AM -0700, Randy Dunlap wrote:
> Hi,
> 
> On 10/8/26 11:06 AM, Stanislav Kinsburskii wrote:
> > Filesystems serving cached content may not need per-open state for most
> > inodes, while still relying on OPEN for control files. The connection-wide
> > no-open behavior selected by ENOSYS cannot express this distinction.
> > 
> > Add FUSE_PER_INODE_NO_OPEN to INIT negotiation and FUSE_ATTR_NO_OPEN to
> > inode attributes. For marked inodes, use the existing zero-handle defaults
> > and normally omit OPEN/OPENDIR and the corresponding RELEASE/RELEASEDIR.
> > Remember whether each handle was opened locally, so later attribute updates
> > do not determine the release behavior of existing handles.
> > 
> > Retain RELEASE after a successful remote flock operation, even when OPEN
> > was skipped, so FUSE_RELEASE_FLOCK_UNLOCK can clean up server-side locks.
> > Servers negotiating remote flock must accept this RELEASE with a zero file
> > handle and no preceding OPEN, including after an explicit unlock.
> > 
> > Keep the release argument allocation for regular files, which pins the
> > inode while asynchronous I/O completes. Honor the hint for internal opens
> > used by file-attribute ioctls as well. The capability check excludes CUSE
> > before accessing its non-FUSE inode as a fuse_inode.
> > 
> > The per-inode hint does not suppress OPEN for atomic O_TRUNC, since the
> > server must perform the truncation. CREATE retains its existing handle
> > lifecycle. Connection-wide no-open/no-opendir behavior selected by ENOSYS
> > continues to take precedence.
> > 
> > Update the cached hint from LOOKUP, GETATTR, SETATTR and READDIRPLUS
> > attributes. Preserve it across STATX replies, which do not carry
> > fuse_attr.flags.
> > 
> > Document negotiation, cache and handle semantics, and the server's
> > responsibilities. No additional access-time or open-reference accounting
> > is introduced.
> > 
> > Signed-off-by: Stanislav Kinsburskii <skinsburskii@gmail.com>
> > ---
> >  Documentation/filesystems/fuse/fuse-no-open.rst | 49 +++++++++++++++++++++++++
> >  Documentation/filesystems/fuse/index.rst        |  1 +
> >  fs/fuse/file.c                                  | 26 ++++++++++---
> >  fs/fuse/fuse_i.h                                | 17 ++++++++-
> >  fs/fuse/inode.c                                 |  9 +++++
> >  fs/fuse/ioctl.c                                 |  3 +-
> >  include/uapi/linux/fuse.h                       | 13 ++++++-
> >  7 files changed, 110 insertions(+), 8 deletions(-)
> > 
> > diff --git a/Documentation/filesystems/fuse/fuse-no-open.rst b/Documentation/filesystems/fuse/fuse-no-open.rst
> > new file mode 100644
> > index 000000000000..4526512d358c
> > --- /dev/null
> > +++ b/Documentation/filesystems/fuse/fuse-no-open.rst
> > @@ -0,0 +1,49 @@
> > +.. SPDX-License-Identifier: GPL-2.0
> > +
> > +Per-inode open suppression
> > +=========================
> 
> Documentation/filesystems/fuse/fuse-no-open.rst:4: WARNING: Title underline too short.
> 
> Per-inode open suppression
> ========================= [docutils]
> 

Addresed in v3.

Thank you,
Stanislav

> > +
> > +A filesystem can avoid OPEN and RELEASE requests for individual inodes by
> > +negotiating FUSE_PER_INODE_NO_OPEN in INIT and setting FUSE_ATTR_NO_OPEN in
> > +``fuse_attr.flags``.  For directories, the flag suppresses OPENDIR and
> > +RELEASEDIR instead.  This allows, for example, cached content files to avoid
> > +open round trips while control files on the same connection retain their
> > +open handlers.  Without the negotiated capability the attribute is ignored.
> > +
> > +The kernel updates the hint when it accepts attributes in replies such as
> > +LOOKUP, GETATTR, SETATTR and READDIRPLUS.  STATX replies do not carry
> > +``fuse_attr.flags`` and leave the hint unchanged.  The hint is cached inode
> > +state; it is not independently revalidated on every open.  A server changing
> > +the hint must arrange for fresh attributes to reach the kernel and tolerate
> > +concurrent opens using the previous value.
> > +
> > +For an open served locally, the file handle is zero, FOPEN_KEEP_CACHE is
> > +set, and directories also have FOPEN_CACHE_DIR set.  Subsequent requests
> > +identify the object by the node ID and may carry a zero file handle.  The
> > +server must support these requests without per-open state.  Whether OPEN was
> > +sent is recorded for each handle and is not changed by later attribute
> > +updates.  An existing server-opened handle still receives its matching
> > +RELEASE if the inode hint subsequently becomes set.
> > +
> > +Remote flock locking is an exception to RELEASE suppression.  When
> > +FUSE_FLOCK_LOCKS is negotiated and a handle has successfully performed a
> > +server-side flock operation, its final close sends RELEASE with
> > +FUSE_RELEASE_FLOCK_UNLOCK and the lock owner, even if OPEN was suppressed.
> > +The server must accept this RELEASE with a zero file handle and no preceding
> > +OPEN, and use the node ID and lock owner to remove any remaining flock locks.
> > +This also applies after an explicit unlock, since the kernel records whether
> > +a flock operation succeeded rather than tracking the server's current locks.
> > +
> > +When FUSE_ATOMIC_O_TRUNC is negotiated, an open with O_TRUNC still sends
> > +OPEN and receives a matching RELEASE, so the server can perform truncation.
> > +CREATE also retains its usual open and release semantics.  Connection-wide
> > +no-open behavior selected by an ENOSYS response continues to take precedence.
> > +
> > +The hint does not make an inode immutable, grant permissions, or suppress
> > +other operations such as FLUSH, FSYNC, locking or data I/O.  Servers supporting
> > +remote flock must implement the RELEASE cleanup described above.  A server must
> > +only set it when its access policy and file semantics permit the default
> > +open behavior described above.  Servers needing per-open authorization,
> > +nonzero handles, direct I/O, passthrough or other OPEN reply flags must keep
> > +handling OPEN for those inodes.  No additional access-time or open-reference
> > +accounting is performed by this feature.
> 
> 
> -- 
> ~Randy
> 

  reply	other threads:[~2026-10-08 19:21 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-08 18:06 [PATCH v2 0/2] fuse: support per-inode open and release suppression Stanislav Kinsburskii
2026-10-08 18:06 ` [PATCH v2 1/2] fuse: add negotiated " Stanislav Kinsburskii
2026-10-08 18:17   ` Randy Dunlap
2026-10-08 19:21     ` Stanislav Kinsburskii [this message]
2026-10-08 18:06 ` [PATCH v2 2/2] selftests: fuse: test per-inode open suppression Stanislav Kinsburskii

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=asftTiSldKhdNEYA@skinsburskii \
    --to=skinsburskii@gmail.com \
    --cc=byrnes@wildpumpkin.net \
    --cc=corbet@lwn.net \
    --cc=fuse-devel@lists.linux.dev \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=rdunlap@infradead.org \
    --cc=shuah@kernel.org \
    --cc=skhan@linuxfoundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox