fusefs: Add tests for the new -o auto_unmount feature

Add tests for mount_fusefs's new -o auto_unmount feature, recently added
by arrowd.

MFC with: 10037d0978f "fusefs: Implement support for the au

fusefs: Add tests for the new -o auto_unmount feature

Add tests for mount_fusefs's new -o auto_unmount feature, recently added
by arrowd.

MFC with: 10037d0978f "fusefs: Implement support for the auto_unmount"

show more ...

fusefs: Fix a panic when unmounting before init

fusefs would page fault due to the following sequence of events:
* The server did not respond to FUSE_INIT in timely fashion.
* Some other process tri

fusefs: Fix a panic when unmounting before init

fusefs would page fault due to the following sequence of events:
* The server did not respond to FUSE_INIT in timely fashion.
* Some other process tried to do unmount.
* That other process got killed by a signal.
* The server finally responded to FUSE_INIT.

PR: 287438
MFC after: 2 weeks
Sponsored by: ConnectWise
Reviewed by: arrowd
Differential Revision: https://reviews.freebsd.org/D50799

show more ...

fusefs: revert a workaround for a googletest bug

This bug was fixed by googletest back in 2019 and released in googletest
1.10.0, I think. Using GTEST_SKIP from a test environment works now.

https

fusefs: revert a workaround for a googletest bug

This bug was fixed by googletest back in 2019 and released in googletest
1.10.0, I think. Using GTEST_SKIP from a test environment works now.

https://github.com/google/googletest/issues/2189

MFC after: 2 weeks
Sponsored by: ConnectWise

show more ...

fusefs: add a test for the max_read= mount option

When set, this limits the amount of data that the kernel will request of
the server in any single read operation. The option has always been
availa

fusefs: add a test for the max_read= mount option

When set, this limits the amount of data that the kernel will request of
the server in any single read operation. The option has always been
available in our fusefs implementation, but never covered by the test
suite.

MFC after: 2 weeks
Sponsored by: ConnectWise

show more ...

tests/fusefs: fix all tests that depend on kern.maxphys

The tests try to read kern.maxphys sysctl into int value, while
unsigned long is required. Not sure when this was broken, seems like
since cd

tests/fusefs: fix all tests that depend on kern.maxphys

The tests try to read kern.maxphys sysctl into int value, while
unsigned long is required. Not sure when this was broken, seems like
since cd8537910406e.

Reviewed by: asomers
Differential Revision: https://reviews.freebsd.org/D45053

show more ...

Remove $FreeBSD$: two-line .h pattern

Remove /^\s*\*\n \*\s+\$FreeBSD\$$\n/

spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD

The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of

spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD

The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.

Discussed with: pfg
MFC After: 3 days
Sponsored by: Netflix

show more ...

fusefs: fix a buffer overflow in the tests

The actual overflow occured in the ReadAhead.readahead test.
Surprisingly it has never segfaulted or resulted in any bad behavior.

MFC after: 1 week
Spons

fusefs: fix a buffer overflow in the tests

The actual overflow occured in the ReadAhead.readahead test.
Surprisingly it has never segfaulted or resulted in any bad behavior.

MFC after: 1 week
Sponsored by: Axcient
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D38718

show more ...

fusefs: use the fsname mount option if set

The daemon can specify fsname=XXX in its mount options. If so, the file
system should report f_mntfromname as XXX during statfs. This will show
up in the

fusefs: use the fsname mount option if set

The daemon can specify fsname=XXX in its mount options. If so, the file
system should report f_mntfromname as XXX during statfs. This will show
up in the output of commands like mount and df.

Submitted by: Ali Abdallah <ali.abdallah@suse.com>
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D35090

show more ...

fusefs: add a test for the subtype= option

At mount time server can set, for example, "subtype=xfs", so that
mount(8) will later show the mountpoint's file system as "fusefs.xfs".
fusefs has had thi

fusefs: add a test for the subtype= option

At mount time server can set, for example, "subtype=xfs", so that
mount(8) will later show the mountpoint's file system as "fusefs.xfs".
fusefs has had this feature ever since the original GSoC commit in 2012,
but there's never been a test for it.

MFC after: 2 weeks

show more ...

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 ...

fusefs: implement VOP_ALLOCATE

Now posix_fallocate will be correctly forwarded to fuse file system
servers, for those that support it.

MFC after: 2 weeks
Reviewed by: pfg
Differential Revision: htt

fusefs: implement VOP_ALLOCATE

Now posix_fallocate will be correctly forwarded to fuse file system
servers, for those that support it.

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

show more ...

fusefs: move common code from forget.cc to utils.cc

MFC after: 2 weeks

fusefs: invalidate the cache during copy_file_range

FUSE_COPY_FILE_RANGE instructs the server to write data to a file.
fusefs must invalidate any cached data within the written range.

PR: 260242
M

fusefs: invalidate the cache during copy_file_range

FUSE_COPY_FILE_RANGE instructs the server to write data to a file.
fusefs must invalidate any cached data within the written range.

PR: 260242
MFC after: 2 weeks
Reviewed by: pfg
Differential Revision: https://reviews.freebsd.org/D33280

show more ...

fusefs: update atime on reads when using cached attributes

When using cached attributes, whether or not the data cache is enabled,
fusefs must update a file's atime whenever it reads from it, so lon

fusefs: update atime on reads when using cached attributes

When using cached attributes, whether or not the data cache is enabled,
fusefs must update a file's atime whenever it reads from it, so long as
it wasn't mounted with -o noatime. Update it in-kernel, and flush it to
the server on close or during the next setattr operation.

The downside is that close() will now frequently trigger a FUSE_SETATTR
upcall. But if you care about performance, you should be using
-o noatime anyway.

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

show more ...

fusefs: fix an expectation in one of the tests

An order-of-operations problem caused an expectation intended for
FUSE_READ to instead match FUSE_ACCESS. Surprisingly, only one test
case was affecte

fusefs: fix an expectation in one of the tests

An order-of-operations problem caused an expectation intended for
FUSE_READ to instead match FUSE_ACCESS. Surprisingly, only one test
case was affected.

MFC after: 2 weeks
Reviewed by: cem
Differential Revision: https://reviews.freebsd.org/D27818

show more ...

fusefs: fix the tests for a wider range of maxphys

maxphys is now a tunable, ever since r368124. The default value is also
larger than it used to be. That broke several fusefs tests that made
assu

fusefs: fix the tests for a wider range of maxphys

maxphys is now a tunable, ever since r368124. The default value is also
larger than it used to be. That broke several fusefs tests that made
assumptions about maxphys.

* WriteCluster.clustering used the MAXPHYS compile-time constant.

* WriteBackAsync.direct_io_partially_overlaps_cached_block implicitly
depended on the default value of maxphys. Fix it by making the
dependency explicit.

* Write.write_large implicitly assumed that maxphys would be no more
than twice maxbcachebuf. Fix it by explicitly setting m_max_write.

* WriteCluster.clustering and several others failed because the MockFS
module did not work for max_write > 128KB (which most tests would set
when maxphys > 256KB). Limit max_write accordingly. This is the same
as fusefs-libs's behavior.

* Bmap's tests were originally written for MAXPHYS=128KB. With larger
values, the simulated file size was too small.

PR: 252096
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D27769

show more ...

Fix issues with FUSE_ACCESS when default_permissions is disabled

This patch fixes two issues relating to FUSE_ACCESS when the
default_permissions mount option is disabled:

* VOP_ACCESS() calls with

Fix issues with FUSE_ACCESS when default_permissions is disabled

This patch fixes two issues relating to FUSE_ACCESS when the
default_permissions mount option is disabled:

* VOP_ACCESS() calls with VADMIN set should never be sent to a fuse server
in the form of FUSE_ACCESS operations. The FUSE protocol has no equivalent
of VADMIN, so we must evaluate such things kernel-side, regardless of the
default_permissions setting.

* The FUSE protocol only requires FUSE_ACCESS to be sent for two purposes:
for the access(2) syscall and to check directory permissions for
searchability during lookup. FreeBSD sends it much more frequently, due to
differences between our VFS and Linux's, for which FUSE was designed. But
this patch does eliminate several cases not required by the FUSE protocol:

* for any FUSE_*XATTR operation
* when creating a new file
* when deleting a file
* when setting timestamps, such as by utimensat(2).

* Additionally, when default_permissions is disabled, this patch removes one
FUSE_GETATTR operation when deleting a file.

PR: 245689
Reported by: MooseFS FreeBSD Team <freebsd@moosefs.pro>
Reviewed by: cem
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D24777

show more ...

Resolve conflict between the fusefs(5) and mac_bsdextended(4) tests

mac_bsdextended(4), when enabled, causes ordinary operations to send many
more VOP_GETATTRs to file system. The fusefs tests expec

Resolve conflict between the fusefs(5) and mac_bsdextended(4) tests

mac_bsdextended(4), when enabled, causes ordinary operations to send many
more VOP_GETATTRs to file system. The fusefs tests expectations aren't
written with those in mind. Optionally expecting them would greatly
obfuscate the fusefs tests. Worse, certain fusefs functionality (like
attribute caching) would be impossible to test if the tests couldn't expect
an exact number of GETATTR operations.

This commit resolves that conflict by making two changes:

1. The fusefs tests will now check for mac_bsdextended, and skip if it's
enabled.
2. The mac_bsdextended tests will now check whether the module is enabled, not
merely loaded. If it's loaded but disabled, the tests will automatically
enable it for the duration of the tests.

With these changes, a CI system can achieve best coverage by loading both
fusefs and mac_bsdextended at boot, and setting
security.mac.bsdextended.enabled=0

PR: 244229
Reported by: lwhsu
Reviewed by: cem
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D24577

show more ...

fusefs: avoid cache corruption with buggy fuse servers

The FUSE protocol allows the client (kernel) to cache a file's size, if the
server (userspace daemon) allows it. A well-behaved daemon obviousl

fusefs: avoid cache corruption with buggy fuse servers

The FUSE protocol allows the client (kernel) to cache a file's size, if the
server (userspace daemon) allows it. A well-behaved daemon obviously should
not change a file's size while a client has it cached. But a buggy daemon
might. If the kernel ever detects that that has happened, then it should
invalidate the entire cache for that file. Previously, we would not only
cache stale data, but in the case of a file extension while we had the size
cached, we accidentally extended the cache with zeros.

PR: 244178
Reported by: Ben RUBSON <ben.rubson@gmx.com>
Reviewed by: cem
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D24012

show more ...

fusefs: coverity cleanup in the tests

Address the following defects reported by Coverity:

* Structurally dead code (CID 1404366): set m_quit before FAIL, not after

* Unchecked return value of sysc

fusefs: coverity cleanup in the tests

Address the following defects reported by Coverity:

* Structurally dead code (CID 1404366): set m_quit before FAIL, not after

* Unchecked return value of sysctlbyname (CID 1404321)

* Unchecked return value of stat(2) (CID 1404471)

* Unchecked return value of open(2) (CID 1404402, 1404529)

* Unchecked return value of dup(2) (CID 1404478)

* Buffer overflows. These are all false positives caused by the fact that
Coverity thinks I'm using a buffer to store strings, when in fact I'm
really just using it to store a byte array that happens to be initialized
with a string. I'm changing the type from char to uint8_t in the hopes
that it will placate Coverity. (CID 1404338, 1404350, 1404367, 1404376,
1404379, 1404381, 1404388, 1404403, 1404425, 1404433, 1404434, 1404474,
1404480, 1404484, 1404503, 1404505)

* False positive file descriptor leak. I'm going to try to fix this with
Coverity modeling, but I'll also change an EXPECT to ASSERT so we don't
perform meaningless assertions after the failure. (CID 1404320, 1404324,
1404440, 1404445).

* Unannotated file descriptor leak. This will be followed up by a Coverity
modeling change. (CID 1404326, 1404334, 1404336, 1404357, 1404361,
1404372, 1404391, 1404395, 1404409, 1404430, 1404448, 1404451, 1404455,
1404457, 1404458, 1404460)

* Uninitialized variables in C++ constructors (CID 1404327, 1404346). In the
case of m_maxphys, this actually led to part of the FUSE_INIT's response
being set to stack garbage during the WriteCluster::clustering test.

* Uninitialized sun_len field in struct sockaddr_un (CID 1404330, 1404371,
1404429).

Reported by: Coverity
Reviewed by: emaste
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D21457

show more ...

fusefs: skip some tests when unsafe aio is disabled

MFC after: 15 days
MFC-With: r350665
Sponsored by: The FreeBSD Foundation

fusefs: add SVN Keywords to the test files

Reported by: SVN pre-commit hooks
MFC after: 15 days
MFC-With: r350665
Sponsored by: The FreeBSD Foundation

fusefs: skip some tests when unsafe aio is disabled

MFC after: 16 days
MFC-With: r350665
Sponsored by: The FreeBSD Foundation

fusefs: add a intr/nointr mount option

FUSE file systems can optionally support interrupting outstanding
operations. However, the file system does not identify to the kernel at
mount time whether i

fusefs: add a intr/nointr mount option

FUSE file systems can optionally support interrupting outstanding
operations. However, the file system does not identify to the kernel at
mount time whether it's capable of doing that. Instead it signals its
noncapability by returning ENOSYS to the first FUSE_INTERRUPT operation it
receives. That's a problem for reliable signal delivery, because the kernel
must choose which thread should get a signal before it knows whether the
FUSE server can handle interrupts. The problem is even worse because the
FUSE protocol allows a file system to simply ignore all FUSE_INTERRUPT
operations.

Fix the signal delivery logic by making interruptibility an opt-in mount
option. This will require a corresponding change to libfuse, but not to
most file systems that link to libfuse.

Bump __FreeBSD_version due to the new mount option.

Sponsored by: The FreeBSD Foundation

show more ...