History log of /freebsd/sys/fs/fuse/fuse_device.c (Results 1 – 25 of 38)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 98999852 13-Dec-2024 Alan Somers <asomers@FreeBSD.org>

fusefs: FUSE_NOTIFY_INVAL_* must busy the mountpoint

Unusually, the FUSE_NOTIFY_INVAL_INODE and FUSE_NOTIFY_INVAL_ENTRY
messages are fully asynchronous. The server sends them to the kernel
unsolici

fusefs: FUSE_NOTIFY_INVAL_* must busy the mountpoint

Unusually, the FUSE_NOTIFY_INVAL_INODE and FUSE_NOTIFY_INVAL_ENTRY
messages are fully asynchronous. The server sends them to the kernel
unsolicited. That means that unlike every other fuse message coming
from the server, these two arrive to a potentially unbusied mountpoint.
So they must explicitly busy it. Otherwise a page fault could result if
the mountpoint were being unmounted.

Reported by: JSML4ThWwBID69YC@protonmail.com
MFC after: 2 weeks

show more ...


Revision tags: release/14.2.0
# ef9ffb85 25-Nov-2024 Mark Johnston <markj@FreeBSD.org>

kern: Make fileops and filterops tables const where possible

No functional change intended.

MFC after: 1 week


Revision tags: release/13.4.0, release/14.1.0, release/13.3.0
# fdafd315 24-Nov-2023 Warner Losh <imp@FreeBSD.org>

sys: Automated cleanup of cdefs and other formatting

Apply the following automated changes to try to eliminate
no-longer-needed sys/cdefs.h includes as well as now-empty
blank lines in a row.

Remov

sys: Automated cleanup of cdefs and other formatting

Apply the following automated changes to try to eliminate
no-longer-needed sys/cdefs.h includes as well as now-empty
blank lines in a row.

Remove /^#if.*\n#endif.*\n#include\s+<sys/cdefs.h>.*\n/
Remove /\n+#include\s+<sys/cdefs.h>.*\n+#if.*\n#endif.*\n+/
Remove /\n+#if.*\n#endif.*\n+/
Remove /^#if.*\n#endif.*\n/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/types.h>/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/param.h>/
Remove /\n+#include\s+<sys/cdefs.h>\n#include\s+<sys/capsicum.h>/

Sponsored by: Netflix

show more ...


Revision tags: release/14.0.0
# 685dc743 16-Aug-2023 Warner Losh <imp@FreeBSD.org>

sys: Remove $FreeBSD$: one-line .c pattern

Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/


Revision tags: release/13.2.0, release/12.4.0, release/13.1.0
# 155ac516 15-Apr-2022 Alan Somers <asomers@FreeBSD.org>

fusefs: validate servers' error values

Formerly fusefs would pass up the stack any error value returned by the
fuse server. However, some values aren't valid for userland, but have
special meanings

fusefs: validate servers' error values

Formerly fusefs would pass up the stack any error value returned by the
fuse server. However, some values aren't valid for userland, but have
special meanings within the kernel. One of these, EJUSTRETURN, could
cause a kernel page fault if the server returned it in response to
FUSE_LOOKUP. Fix by validating all errors returned by the server.

Also, fix a data lifetime bug in the FUSE_DESTROY test.

PR: 263220
Reported by: Robert Morris <rtm@lcs.mit.edu>
MFC after: 3 weeks
Sponsored by: Axcient
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D34931

show more ...


Revision tags: release/12.3.0
# df38ada2 17-Nov-2021 Bjoern A. Zeeb <bz@FreeBSD.org>

modules: increase MAXMODNAME and provide backward compat

With various firmware files used by graphics and wireless drivers
we are exceeding the current 32 character module name (file path
in kldxref

modules: increase MAXMODNAME and provide backward compat

With various firmware files used by graphics and wireless drivers
we are exceeding the current 32 character module name (file path
in kldxref) length.
In order to overcome this issue bump it to the maximum path length
for the next version.
To be able to MFC provide backward compat support for another version
of the struct as the offsets for the second half change due to the
array size increase.

MAXMODNAME being defined to MAXPATHLEN needs param.h to be
included first. With only 7 modules (or LinuxKPI module.h) not
doing that adjust them rather than including param.h in module.h [1].

Reported by: Greg V (greg unrelenting.technology)
Sponsored by: The FreeBSD Foundation
Suggested by: imp [1]
MFC after: 10 days
Reviewed by: imp (and others to different level)
Differential Revision: https://reviews.freebsd.org/D32383

show more ...


# 9b876fbd 16-Jun-2021 gAlfonso-bit <83477269+gAlfonso-bit@users.noreply.github.com>

Simplify fuse_device_filt_write

It always returns 1, so why bother having a variable.

MFC after: 2 weeks
MFC with: 7b8622fa220b9c08041102f638f848c48e022644
Pull Request: https://github.com/freebsd/

Simplify fuse_device_filt_write

It always returns 1, so why bother having a variable.

MFC after: 2 weeks
MFC with: 7b8622fa220b9c08041102f638f848c48e022644
Pull Request: https://github.com/freebsd/freebsd-src/pull/478

show more ...


# 7b8622fa 16-Jun-2021 Alan Somers <asomers@FreeBSD.org>

fusefs: support EVFILT_WRITE on /dev/fuse

/dev/fuse is always ready for writing, so it's kind of dumb to poll it.
But some applications do it anyway. Better to return ready than EINVAL.

MFC after:

fusefs: support EVFILT_WRITE on /dev/fuse

/dev/fuse is always ready for writing, so it's kind of dumb to poll it.
But some applications do it anyway. Better to return ready than EINVAL.

MFC after: 2 weeks
Reviewed by: emaste, pfg
Differential Revision: https://reviews.freebsd.org/D30784

show more ...


Revision tags: release/13.0.0
# 4f4111d2 24-Dec-2020 Alan Somers <asomers@FreeBSD.org>

fusefs: delete some dead code

The original fusefs GSoC project seems to have envisioned exchanging two
types of messages with FUSE servers. Perhaps vectored and non-vectored?
But in practice only o

fusefs: delete some dead code

The original fusefs GSoC project seems to have envisioned exchanging two
types of messages with FUSE servers. Perhaps vectored and non-vectored?
But in practice only one type has ever been used. Delete the other type.

Reviewed by: cem
Differential Revision: https://reviews.freebsd.org/D27770

show more ...


# e3b1c847 09-Nov-2020 Edward Tomasz Napierala <trasz@FreeBSD.org>

Make it possible to mount a fuse filesystem, such as squashfuse,
from a Linux binary. Should come handy for AppImages.

Reviewed by: asomers
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
D

Make it possible to mount a fuse filesystem, such as squashfuse,
from a Linux binary. Should come handy for AppImages.

Reviewed by: asomers
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D26959

show more ...


Revision tags: release/12.2.0, release/11.4.0, release/12.1.0
# 0b4275ac 07-Aug-2019 Alan Somers <asomers@FreeBSD.org>

fusefs: merge from projects/fuse2

This commit imports the new fusefs driver. It raises the protocol level
from 7.8 to 7.23, fixes many bugs, adds a test suite for the driver, and
adds many new featu

fusefs: merge from projects/fuse2

This commit imports the new fusefs driver. It raises the protocol level
from 7.8 to 7.23, fixes many bugs, adds a test suite for the driver, and
adds many new features. New features include:

* Optional kernel-side permissions checks (-o default_permissions)
* Implement VOP_MKNOD, VOP_BMAP, and VOP_ADVLOCK
* Allow interrupting FUSE operations
* Support named pipes and unix-domain sockets in fusefs file systems
* Forward UTIME_NOW during utimensat(2) to the daemon
* kqueue support for /dev/fuse
* Allow updating mounts with "mount -u"
* Allow exporting fusefs file systems over NFS
* Server-initiated invalidation of the name cache or data cache
* Respect RLIMIT_FSIZE
* Try to support servers as old as protocol 7.4

Performance enhancements include:

* Implement FUSE's FOPEN_KEEP_CACHE and FUSE_ASYNC_READ flags
* Cache file attributes
* Cache lookup entries, both positive and negative
* Server-selectable cache modes: writethrough, writeback, or uncached
* Write clustering
* Readahead
* Use counter(9) for statistical reporting

PR: 199934 216391 233783 234581 235773 235774 235775
PR: 236226 236231 236236 236291 236329 236381 236405
PR: 236327 236466 236472 236473 236474 236530 236557
PR: 236560 236844 237052 237181 237588 238565
Reviewed by: bcr (man pages)
Reviewed by: cem, ngie, rpokala, glebius, kib, bde, emaste (post-commit
review on project branch)
MFC after: 3 weeks
Relnotes: yes
Sponsored by: The FreeBSD Foundation
Pull Request: https://reviews.freebsd.org/D21110

show more ...


Revision tags: release/11.3.0
# 7e1f5432 28-Jun-2019 Alan Somers <asomers@FreeBSD.org>

fusefs: don't leak memory of unsent operations on unmount

Sponsored by: The FreeBSD Foundation


# 8aafc8c3 28-Jun-2019 Alan Somers <asomers@FreeBSD.org>

[skip ci] update copyright headers in fusefs files

Sponsored by: The FreeBSD Foundation


# c1afff11 28-Jun-2019 Alan Somers <asomers@FreeBSD.org>

fusefs: fix a memory leak regarding FUSE_INTERRUPT

We were leaking the fuse ticket if the original operation completed before
the daemon received the INTERRUPT operation. Fixing this was easier tha

fusefs: fix a memory leak regarding FUSE_INTERRUPT

We were leaking the fuse ticket if the original operation completed before
the daemon received the INTERRUPT operation. Fixing this was easier than I
expected.

Sponsored by: The FreeBSD Foundation

show more ...


# 7cbb8e8a 21-Jun-2019 Alan Somers <asomers@FreeBSD.org>

fusefs: raise protocol level to 7.15

This protocol level adds two new features: the ability for the server to
store or retrieve data into/from the client's cache. But the messages
aren't defined so

fusefs: raise protocol level to 7.15

This protocol level adds two new features: the ability for the server to
store or retrieve data into/from the client's cache. But the messages
aren't defined soundly since they identify the file only by its inode,
without the generation number. So it's possible for them to modify the
wrong file's cache. Also, I don't know of any file systems in ports that
use these messages. So I'm not implementing them. I did add a (disabled)
test for the store message, however.

Sponsored by: The FreeBSD Foundation

show more ...


# eae1ae13 03-Jun-2019 Alan Somers <asomers@FreeBSD.org>

fusefs: support asynchronous cache invalidation

Protocol 7.12 adds a way for the server to notify the client that it should
invalidate an inode's data cache and/or attributes. This commit implement

fusefs: support asynchronous cache invalidation

Protocol 7.12 adds a way for the server to notify the client that it should
invalidate an inode's data cache and/or attributes. This commit implements
that mechanism. Unlike Linux's implementation, ours requires that the file
system also supports FUSE_EXPORT_SUPPORT (NFS-style lookups). Otherwise the
invalidation operation will return EINVAL.

Sponsored by: The FreeBSD Foundation

show more ...


# c2d70d6e 01-Jun-2019 Alan Somers <asomers@FreeBSD.org>

fusefs: support name cache invalidation

Protocol 7.12 adds a way for the server to notify the client that it should
invalidate an entry from its name cache. This commit implements that
mechanism.

fusefs: support name cache invalidation

Protocol 7.12 adds a way for the server to notify the client that it should
invalidate an entry from its name cache. This commit implements that
mechanism.

Sponsored by: The FreeBSD Foundation

show more ...


# 0a7c63e0 12-May-2019 Alan Somers <asomers@FreeBSD.org>

fusefs: Report the number of available ops in kevent(2)

Just like /dev/devctl, /dev/fuse will now report the number of operations
available for immediate read in the kevent.data field during kevent(

fusefs: Report the number of available ops in kevent(2)

Just like /dev/devctl, /dev/fuse will now report the number of operations
available for immediate read in the kevent.data field during kevent(2).

Sponsored by: The FreeBSD Foundation

show more ...


# 3429092c 12-May-2019 Alan Somers <asomers@FreeBSD.org>

fusefs: support kqueue for /dev/fuse

/dev/fuse was already pollable with poll and select. Add support for
kqueue, too. And add tests for polling with poll, select, and kqueue.

Sponsored by: The F

fusefs: support kqueue for /dev/fuse

/dev/fuse was already pollable with poll and select. Add support for
kqueue, too. And add tests for polling with poll, select, and kqueue.

Sponsored by: The FreeBSD Foundation

show more ...


# 8b73a4c5 10-May-2019 Alan Somers <asomers@FreeBSD.org>

fusefs: fix running multiple daemons concurrently

When a FUSE daemon dies or closes /dev/fuse, all of that daemon's pending
requests must be terminated. Previously that was done in /dev/fuse's
.d_c

fusefs: fix running multiple daemons concurrently

When a FUSE daemon dies or closes /dev/fuse, all of that daemon's pending
requests must be terminated. Previously that was done in /dev/fuse's
.d_close method. However, d_close only gets called on the *last* close of
the device. That means that if multiple daemons were running concurrently,
all but the last daemon to close would leave their I/O hanging around. The
problem was easily visible just by running "kyua -v parallelism=2 test" in
fusefs's test directory.

Fix this bug by terminating a daemon's pending I/O during /dev/fuse's
cdvpriv dtor method instead. That method runs on every close of a file.

Also, fix some potential races in the tests:
* Clear SA_RESTART when registering the daemon's signal handler so read(2)
will return EINTR.
* Wait for the daemon to die before unmounting the mountpoint, so we won't
see an unwanted FUSE_DESTROY operation in the mock file system.

Sponsored by: The FreeBSD Foundation

show more ...


# 419e7ff6 20-Apr-2019 Alan Somers <asomers@FreeBSD.org>

fusefs: rename the SDT probes from "fuse" to "fusefs"

This matches the new name of the kld.

Sponsored by: The FreeBSD Foundation


# a1542146 18-Apr-2019 Alan Somers <asomers@FreeBSD.org>

fusefs: improvements to interruptibility

* If a process receives a fatal signal while blocked on a fuse operation,
return ASAP without waiting for the operation to complete. But still send
the

fusefs: improvements to interruptibility

* If a process receives a fatal signal while blocked on a fuse operation,
return ASAP without waiting for the operation to complete. But still send
the FUSE_INTERRUPT op to the daemon.
* Plug memory leaks from r346339

Interruptibility is now fully functional, but it could be better:
* Operations that haven't been sent to the server yet should be aborted
without sending FUSE_INTERRUPT.
* It would be great if write operations could be made restartable.
That would require delaying uiomove until the last possible moment, which
would be sometime during fuse_device_read.
* It would be nice if we didn't have to guess which EAGAIN responses were
for FUSE_INTERRUPT operations.

PR: 236530
Sponsored by: The FreeBSD Foundation

show more ...


# 723c7768 18-Apr-2019 Alan Somers <asomers@FreeBSD.org>

fusefs: WIP making FUSE operations interruptible

The fuse protocol includes a FUSE_INTERRUPT operation that the client can
send to the server to indicate that it wants to abort an in-progress
operat

fusefs: WIP making FUSE operations interruptible

The fuse protocol includes a FUSE_INTERRUPT operation that the client can
send to the server to indicate that it wants to abort an in-progress
operation. It's required to interrupt any syscall that is blocking on a
fuse operation.

This commit adds basic FUSE_INTERRUPT support. If a process receives any
signal while it's blocking on a FUSE operation, it will send a
FUSE_INTERRUPT and wait for the original operation to complete. But there
is still much to do:

* The current code will leak memory if the server ignores FUSE_INTERRUPT,
which many do. It will also leak memory if the server completes the
original operation before it receives the FUSE_INTERRUPT.
* An interrupted read(2) will incorrectly appear to be successful.
* fusefs should return immediately for fatal signals.
* Operations that haven't been sent to the server yet should be aborted
without sending FUSE_INTERRUPT.
* Test coverage should be better.
* It would be great if write operations could be made restartable.
That would require delaying uiomove until the last possible moment, which
would be sometime during fuse_device_read.

PR: 236530
Sponsored by: The FreeBSD Foundation

show more ...


# b4227f34 12-Apr-2019 Alan Somers <asomers@FreeBSD.org>

fusefs: /dev/fuse should be 0666

The fuse protocol is designed with security in mind. It prevents users from
spying on each others' activities. And it doesn't grant users any
privileges that they

fusefs: /dev/fuse should be 0666

The fuse protocol is designed with security in mind. It prevents users from
spying on each others' activities. And it doesn't grant users any
privileges that they didn't already have. So it's appropriate to make it
available to everyone. Plus, it's necessary in order for kyua to run tests
as an unprivileged user.

Sponsored by: The FreeBSD Foundation

show more ...


# 080518d8 29-Mar-2019 Alan Somers <asomers@FreeBSD.org>

fusefs: convert debug printfs into dtrace probes

fuse(4) was heavily instrumented with debug printf statements that could
only be enabled with compile-time flags. They fell into three basic groups:

fusefs: convert debug printfs into dtrace probes

fuse(4) was heavily instrumented with debug printf statements that could
only be enabled with compile-time flags. They fell into three basic groups:

1. Totally redundant with dtrace FBT probes. These I deleted.
2. Print textual information, usually error messages. These I converted to
SDT probes of the form fuse:fuse:FILE:trace. They work just like the old
printf statements except they can be enabled at runtime with dtrace. They
can be filtered by FILE and/or by priority.
3. More complicated probes that print detailed information. These I
converted into ad-hoc SDT probes.

Also, de-inline fuse_internal_cache_attrs. It's big enough to be a regular
function, and this way it gets a dtrace FBT probe.

This commit is a merge of r345304, r344914, r344703, and r344664 from
projects/fuse2.

Reviewed by: cem
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D19667

show more ...


12