fuse_set_conn_flag() collects the libfuse-side connection hints that are
not negotiated with the kernel. no_interrupt was the one such hint still
set only by direct field assignment.
Define FUSE_CONN_FLAG_NO_INTERRUPT alongside FUSE_CONN_FLAG_SINGLE_ISSUER
and map it onto conn->no_interrupt in the same switch, and convert the
example init() handlers to set it through the setter.
Signed-off-by: Bernd Schubert <bernd@bsbernd.com>
Part 1 dropped cqe_processing and made the serving loop wait-only, so
the default path now issues one io_uring_submit() per inline reply
instead of coalescing a cqe batch into a single submit.
Restore the batching: the loop splits submit_and_wait so the flush
stays under ring_lock (part 1's race fix), and cqe_processing - now an
_Atomic bool set lock-free around handle_cqes() - again gates the
per-reply submit. The SQ stays serialised, so a batched reply is always
flushed before the next wait, never stranded.
Add a conn flag, io_uring_single_issuer, for a filesystem that replies
only from the per-queue uring thread: it skips ring_lock entirely and
runs the combined io_uring_submit_and_wait() loop, sound because only
that thread touches the ring. The flag reuses a reserved padding bit
(ABI unchanged; flag 0 keeps the multi-issuer path) and is mirrored
into the ring pool after op.init(), before serving starts.
A filesystem enables it with fuse_set_conn_flag(conn,
FUSE_CONN_FLAG_SINGLE_ISSUER), a new exported setter modelled on
fuse_set_feature_flag(); the io_uring_single_issuer bitfield is the
internal storage.
Signed-off-by: Bernd Schubert <bernd@bsbernd.com>
Add support for parsing FUSE_SECCTX extensions sent by the kernel
during file creation operations. This allows userspace filesystems
to receive and persist SELinux/AppArmor security labels on newly
created files.
Add example in passthrough_hp: When creating a file, iterates the fuse
req extension security contexts to find the SELinux security label and
apply it.
Signed-off-by: Kevin Chen <kchen@ddn.com>
The fuse_get_feature_flag() function only reads from the conn parameter
and does not modify it. Add const qualifier for API consistency and to
allow callers to pass const pointers.
This is a public API function added in version 3.17.3. Adding const is
ABI-compatible as it only affects source-level type checking.
Fixes cppcheck warning:
- cppcheck-constParameterPointer in fuse_lowlevel.c:2670
Signed-off-by: Bernd Schubert <bernd@bsbernd.com>
Add const qualifiers to various function parameters and local variables:
- Add const to opts parameter in fuse_apply_conn_info_opts (helper.c)
- Add const to config parameter in fuse_loop_cfg_verify (fuse_loop_mt.c)
- Add const to v1_conf parameter in fuse_loop_cfg_convert (fuse_loop_mt.c)
- Add const to f parameter in fuse_mount and fuse_unmount (fuse.c)
- Add const to conflict variable in fuse_lib_getlk (fuse.c)
- Add const to payload, arg, in_buf variables in fuse_lowlevel.c
- Add const to req parameter in find_interrupted (fuse_lowlevel.c)
- Add const to in parameter in fuse_session_in2req (fuse_lowlevel.c)
- Add const to se parameter in fuse_req_check_allow_root (fuse_lowlevel.c)
- Add const to version parameter in fuse_session_new_versioned
(fuse_lowlevel.c)
- Add const to se parameter in fuse_session_fd (fuse_lowlevel.c)
Fixes cppcheck warnings:
- cppcheck-constParameterPointer (12 instances)
- cppcheck-constVariablePointer (5 instances)
Signed-off-by: Bernd Schubert <bernd@bsbernd.com>
- Remove redundant assignment after abort() (unreachable code)
- Remove unreachable assignment of fuse_instance->error after abort()
- Mark signals parameters as const in internal functions
- Mark se parameter as const in fuse_remove_signal_handlers
Fixes cppcheck warnings:
- cppcheck-redundantAssignment
- cppcheck-unreachableCode
- cppcheck-constParameter
- cppcheck-constParameterPointer
Signed-off-by: Bernd Schubert <bernd@bsbernd.com>
* fuse: add FUSE_CAP_ALLOW_IDMAP support
Add FUSE_CAP_ALLOW_IDMAP capability flag to indicate that creation of
idmapped mounts is allowed. This maps to the kernel's FUSE_ALLOW_IDMAP
flag.
- Define FUSE_CAP_ALLOW_IDMAP in fuse_common.h using (1ULL << 32) to
ensure correct behavior on both 32-bit and 64-bit platforms.
- Set the capability in capable_ext when kernel reports FUSE_ALLOW_IDMAP.
- Send FUSE_ALLOW_IDMAP to kernel when userspace sets it in want_ext.
- Add the new FUSE_CAP_ALLOW_IDMAP capability to the printcap example
so it is printed when supported by the kernel.
Signed-off-by: Renzheng Wang <wangrzneu@gmail.com>
fuse_apply_conn_info_opts() was applying to 'want_ext',
which would cause conflicts with 'want' if the application
applied its own flags to 'conn->want'.
Solution is:
- to move fuse_{set,unset,get}_feature_flag and
convert_to_conn_want_ext() to fuse_lowlevel.c and
to define them as part of the public API, although
convert_to_conn_want_ext() should not be used - it is
currently needed to be a public function due as it needs
to be defined for the tests.
Related to https://github.com/libfuse/libfuse/issues/1171 and
https://github.com/libfuse/libfuse/pull/1172.
Closes: https://github.com/libfuse/libfuse/issues/1171
Signed-off-by: Bernd Schubert <bschubert@ddn.com>
This adds the libfuse changes needed to support request timeouts.
A timeout may be set by the server in its init call. If a request is not
completed by the timeout, the connection will be aborted by the kernel.
Signed-off-by: Joanne Koong <joannelkoong@gmail.com>
At the moment build fails due to lack of static_assert:
https://gitlab.com/jolivain/buildroot/-/jobs/9606292537
this means that the check per date is not enough, so let's use meson to
check if static_assert() is present or not and simplify
fuse_static_assert() definition by only checking HAVE_STATIC_ASSERT.
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
The previous fields are left for ABI compatibility, although
it is not beautiful to add that complexity when we have to increase
the so-version as we had ABI breakage anyway.
example/printcap is simplified to use an array, as every line would
have needed to be modified anyway. Missing 'FUSE_CAP_PASSTHROUGH'
was added.
Signed-off-by: Bernd Schubert <bernd@bsbernd.com>
Should be used internally only, but is still in a common file -
we better use arch independent values.
Signed-off-by: Bernd Schubert <bernd@bsbernd.com>
Add a flags and reserved fields to struct fuse_file_info
and add a static assert on the size.
Also add another static assert for 'struct fuse_conn_info'
Signed-off-by: Bernd Schubert <bernd@bsbernd.com>
This fixes commit
a5eb7f2 "Enable parallel direct writes on the same file"
and restores the ABI by moving the parallel_direct_writes
bit.
Given that there were already several releases with this commit
we will still need an so version bump.
Signed-off-by: Bernd Schubert <bernd@bsbernd.com>
A previous PR supported extended max writes (eg write requests larger than 1 MB)
by initializing the fuse session buffer size to use the max_pages_limit set in
/proc/sys/fs/fuse. However, this is a huge problem for machines where multiple
fuse servers may be running but only one server needs large writes. In this case,
a lot of memory will be wasted and will lead to OOM issues.
This PR does a reallocation of the session buffer transparently if the server set
"se->conn.max_write" to a value larger than 1 MiB. This is only for buffers that
are "owned" by libfuse - if the server wishes to provide its own allocated buffer
for receiving/processing requests, then it should ensure that buffer is allocated
to the proper size from the start.
Local testing showed:
echo 65535 | sudo tee /proc/sys/fs/fuse/max_pages_limit
dd if=/dev/urandom of=hello_file bs=6M count=2
write requests:
write request size is 5242880
write request size is 1048576
write request size is 5242880
write request size is 1048576
I see random ENOTCONN failures in xfstest generic/013 and generic/014
in my branch, but earliest on the 2nd run - takes ~12hours to get
the issue, but then there are no further information logged.
ENOTCONN points to a daemon crash - I need backtraces and a core dump.
This adds optional handling of fatal signals to print a core dump
and optional syslog logging with these new public functions:
fuse_set_fail_signal_handlers()
In addition to the existing fuse_set_signal_handlers(). This is not
enabled together with fuse_set_signal_handlers(), as it is change
in behavior and file systems might already have their own fatal
handlers.
fuse_log_enable_syslog
Print logs to syslog instead of stderr
fuse_log_close_syslog
Close syslog (for now just does closelog())
Code in fuse_signals.c is also updated, to be an array of signals,
and setting signal handlers is now down with a for-loop instead
of one hand coded set_one_signal_handler() per signal.
The function fuse_session_process_buf_int() would do much things
for FUSE_INTERRUPT requests, even there are no FUSE_INTERRUPT requests:
1. check every non-FUSE_INTERRUPT request and add these requests to the
linked list(se->list) under a big lock(se->lock).
2. the function fuse_free_req() frees every request and remove them from
the linked list(se->list) under a bing lock(se->lock).
These operations are not meaningful when there are no FUSE_INTERRUPT requests,
and have a great impact on the performance of fuse filesystem because the big
lock for each request.
In some cases, FUSE_INTERRUPT requests are infrequent, even none at all.
Besides, the user-defined filesystem may do nothing for FUSE_INTERRUPT requests.
And the kernel side has the option "no_interrupt" in struct fuse_conn. This kernel option
can be enabled by return ENOSYS in libfuse for the reply of FUSE_INTERRUPT request.
But I don't find the code to enable the "no_interrupt" kernel option in libfuse.
So add the no_interrupt support, and when this operaion is enabled:
1. remove the useless locking operaions and list operations.
2. return ENOSYS for the reply of FUSE_INTERRUPT request to inform the kernel to disable
FUSE_INTERRUPT request.
Add support for filesystem passthrough read/write of files.
When the FUSE_PASSTHROUGH capability is enabled, the FUSE server may
decide, while handling the "open" or "create" requests, if the given
file can be accessed by that process in "passthrough" mode, meaning that
all the further read and write operations would be forwarded by the
kernel directly to the backing file rather than to the FUSE server.
All requests other than read or write are still handled by the server.
This allows for an improved performance on reads and writes, especially
in the case of reads at random offsets, for which no (readahead)
caching mechanism would help, reducing the performance gap between FUSE
and native filesystem access.
Extend also the passthrough_hp example with the new passthrough feature.
This example opens a kernel backing file per FUSE inode on the first
FUSE file open of that inode and closes the backing file on the release
of the last FUSE file on that inode.
All opens of the same inode passthrough to the same backing file.
A combination of fi->direct_io and fi->passthrough is allowed.
It means that read/write operations go directly to the server, but mmap
is done on the backing file.
This allows to open some fds of the inode in passthrough mode and some
fd of the same inode in direct_io/passthrough_mmap mode.
Signed-off-by: Alessio Balsini <balsini@android.com>
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
The API stays the same, the libfuse version comes from
inlined functions, which are defined fuse_lowlevel.h
and fuse.h. As these inlined functions are defined in the header
files they get added into the application, similar as if these
were preprocessor macros.
Macro vs inlined function is then just a style issue - I personally
prefer the latter.
fuse_session_new() -> static inlinei, in the application
_fuse_session_new -> inside of libfuse
fuse_new() -> static inline, in the application
_fuse_new() -> inside of libfuse
Note: Entirely untested is the fuse 30 api - we need a test
for it. And we do not have any ABI tests at all.
Signed-off-by: Bernd Schubert <bernd.schubert@fastmail.fm>
If the file system doesn't provide a ->open or an ->opendir, and the
kernel supports FUSE_CAP_NO_OPEN_SUPPORT or FUSE_CAP_NO_OPENDIR_SUPPORT,
allow the implementation to set FUSE_CAP_NO_OPEN*_SUPPORT on conn->want
in order to automatically get this behavior. Expand the documentation
to be more explicit about the behavior of libfuse in the different cases
WRT this capability.
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
* Use single place to define the version
Defining the version in fuse_common.h, is removed, it is defined
through meson and provided by "libfuse_config.h". I.e. it avoids
to define the version twice - once in meson and once in
fuse_common.h.
Ideal would be to set integers in the meson file and create the version
string from these integers. However, meson requires that "project"
is the first meson.build keyword - with that it requires to
set the version from a string and then major/minor/hotfix integers
are created from string split.
Signed-off-by: Bernd Schubert <bernd.schubert@fastmail.fm>
* Increase the version to 3.17.0
This is to prepare the branch for the next release.
Signed-off-by: Bernd Schubert <bernd.schubert@fastmail.fm>
---------
Signed-off-by: Bernd Schubert <bernd.schubert@fastmail.fm>
Add more documentation for FUSE_CAP_EXPORT_SUPPORT
Also remove the flag from passthrough_ll.c and passthrough_hp.cc
as these implementations do _not_ handle that flag. They just
cast fuse_ino_t to an inode and cause a heap buffer overflow
for unknown objects (simplest reproducer are the examples
in "man 2 open_by_handle_at", but to unmount/mount the file
system after name_to_handle_at and before open_by_handle_at).
Fixes https://github.com/libfuse/libfuse/issues/838
---------
Co-authored-by: Nikolaus Rath <Nikolaus@rath.org>
'FUSE_CAP_HANDLE_KILLPRIV' is not enabled by default anymore, as that
would be a sudden security issue introduced by a new ABI and API
compatible libfuse version.
Allowing parallel dir operations could result in a crash in a filesystem
implementation that is not prepared for this.
To be safe keep this flag off by default (this is not a regression, since
there was no public release where this flag wasn't ignored).
If the filesystem wants better performance, then it should set this flag
explicitly.
Fixes: c9905341ea ("Pass FUSE_PARALLEL_DIROPS to kernel (#861)")
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
This is not called FUSE_CAP_DIRECT_IO_RELAX, as the kernel flag
FUSE_DIRECT_IO_RELAX is supposed to be renamed to
FUSE_DIRECT_IO_ALLOW_MMAP. The corresponding kernel patches just
did not land yet.
This syncs fuse_kernel.h to <linux-6.3>/include/uapi/linux/fuse.h
Special handling is done for setxattr as in linux commit
52a4c95f4d24b struct fuse_setxattr_in was extended. Extended
struct is only used when FUSE_SETXATTR_EXT is passed in FUSE_INIT
reply.
Right now fuse kernel serializes direct writes on the
same file. This serialization is good for such FUSE
implementations which rely on the inode lock to
avoid any data inconsistency issues but it hurts badly
such FUSE implementations which have their own mechanism
of dealing with cache/data integrity and can handle
parallel direct writes on the same file.
This patch allows parallel direct writes on the same file to be
enabled with the help of a flag FOPEN_PARALLEL_DIRECT_WRITES.
FUSE implementations which want to use this feature can
set this flag during fuse init. Default behaviour remains
same i.e no parallel direct writes on the same file.
Corresponding fuse kernel patch(Merged).
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v6.2&id=153524053bbb0d27bb2e0be36d1b46862e9ce74c
Bernd Schubert